home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 98 / Skunkware 98.iso / src / net / t4b-t5b.gz / t4b-t5b
Text File  |  1997-05-01  |  95KB  |  2,433 lines
  1. Index: bind/doc/rfc/rfc2136
  2. diff -c /dev/null bind/doc/rfc/rfc2136:8.1
  3. *** /dev/null    Wed Apr 30 21:24:39 1997
  4. --- bind/doc/rfc/rfc2136    Wed Apr 30 10:27:14 1997
  5. ***************
  6. *** 0 ****
  7. --- 1,1459 ----
  8. + 
  9. + 
  10. + 
  11. + 
  12. + 
  13. + 
  14. + Network Working Group                                  P. Vixie, Editor
  15. + Request for Comments: 2136                                          ISC
  16. + Updates: 1035                                                S. Thomson
  17. + Category: Standards Track                                      Bellcore
  18. +                                                              Y. Rekhter
  19. +                                                                   Cisco
  20. +                                                                J. Bound
  21. +                                                                     DEC
  22. +                                                              April 1997
  23. + 
  24. +          Dynamic Updates in the Domain Name System (DNS UPDATE)
  25. + 
  26. + Status of this Memo
  27. + 
  28. +    This document specifies an Internet standards track protocol for the
  29. +    Internet community, and requests discussion and suggestions for
  30. +    improvements.  Please refer to the current edition of the "Internet
  31. +    Official Protocol Standards" (STD 1) for the standardization state
  32. +    and status of this protocol.  Distribution of this memo is unlimited.
  33. + 
  34. + Abstract
  35. + 
  36. +    The Domain Name System was originally designed to support queries of
  37. +    a statically configured database.  While the data was expected to
  38. +    change, the frequency of those changes was expected to be fairly low,
  39. +    and all updates were made as external edits to a zone's Master File.
  40. + 
  41. +    Using this specification of the UPDATE opcode, it is possible to add
  42. +    or delete RRs or RRsets from a specified zone.  Prerequisites are
  43. +    specified separately from update operations, and can specify a
  44. +    dependency upon either the previous existence or nonexistence of an
  45. +    RRset, or the existence of a single RR.
  46. + 
  47. +    UPDATE is atomic, i.e., all prerequisites must be satisfied or else
  48. +    no update operations will take place.  There are no data dependent
  49. +    error conditions defined after the prerequisites have been met.
  50. + 
  51. + 1 - Definitions
  52. + 
  53. +    This document intentionally gives more definition to the roles of
  54. +    "Master," "Slave," and "Primary Master" servers, and their
  55. +    enumeration in NS RRs, and the SOA MNAME field.  In that sense, the
  56. +    following server type definitions can be considered an addendum to
  57. +    [RFC1035], and are intended to be consistent with [RFC1996]:
  58. + 
  59. +       Slave           an authoritative server that uses AXFR or IXFR to
  60. +                       retrieve the zone and is named in the zone's NS
  61. +                       RRset.
  62. + 
  63. + 
  64. + 
  65. + Vixie, et. al.              Standards Track                     [Page 1]
  66. + 
  67. + RFC 2136                       DNS Update                     April 1997
  68. + 
  69. + 
  70. +       Master          an authoritative server configured to be the
  71. +                       source of AXFR or IXFR data for one or more slave
  72. +                       servers.
  73. + 
  74. +       Primary Master  master server at the root of the AXFR/IXFR
  75. +                       dependency graph.  The primary master is named in
  76. +                       the zone's SOA MNAME field and optionally by an NS
  77. +                       RR.  There is by definition only one primary master
  78. +                       server per zone.
  79. + 
  80. +    A domain name identifies a node within the domain name space tree
  81. +    structure.  Each node has a set (possibly empty) of Resource Records
  82. +    (RRs).  All RRs having the same NAME, CLASS and TYPE are called a
  83. +    Resource Record Set (RRset).
  84. + 
  85. +    The pseudocode used in this document is for example purposes only.
  86. +    If it is found to disagree with the text, the text shall be
  87. +    considered authoritative.  If the text is found to be ambiguous, the
  88. +    pseudocode can be used to help resolve the ambiguity.
  89. + 
  90. +    1.1 - Comparison Rules
  91. + 
  92. +    1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
  93. +    RDLENGTH and RDATA fields are equal.  Note that the time-to-live
  94. +    (TTL) field is explicitly excluded from the comparison.
  95. + 
  96. +    1.1.2. The rules for comparison of character strings in names are
  97. +    specified in [RFC1035 2.3.3].
  98. + 
  99. +    1.1.3. Wildcarding is disabled.  That is, a wildcard ("*") in an
  100. +    update only matches a wildcard ("*") in the zone, and vice versa.
  101. + 
  102. +    1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
  103. +    the update, and will not otherwise be followed.  All UPDATE
  104. +    operations are done on the basis of canonical names.
  105. + 
  106. +    1.1.5. The following RR types cannot be appended to an RRset.  If the
  107. +    following comparison rules are met, then an attempt to add the new RR
  108. +    will result in the replacement of the previous RR:
  109. + 
  110. +       SOA    compare only NAME, CLASS and TYPE -- it is not possible to
  111. +              have more than one SOA per zone, even if any of the data
  112. +              fields differ.
  113. + 
  114. +       WKS    compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
  115. +              -- only one WKS RR is possible for this tuple, even if the
  116. +              services masks differ.
  117. + 
  118. + 
  119. + 
  120. + 
  121. + Vixie, et. al.              Standards Track                     [Page 2]
  122. + 
  123. + RFC 2136                       DNS Update                     April 1997
  124. + 
  125. + 
  126. +       CNAME  compare only NAME, CLASS, and TYPE -- it is not possible
  127. +              to have more than one CNAME RR, even if their data fields
  128. +              differ.
  129. + 
  130. +    1.2 - Glue RRs
  131. + 
  132. +    For the purpose of determining whether a domain name used in the
  133. +    UPDATE protocol is contained within a specified zone, a domain name
  134. +    is "in" a zone if it is owned by that zone's domain name.  See
  135. +    section 7.18 for details.
  136. + 
  137. +    1.3 - New Assigned Numbers
  138. + 
  139. +       CLASS = NONE (254)
  140. +       RCODE = YXDOMAIN (6)
  141. +       RCODE = YXRRSET (7)
  142. +       RCODE = NXRRSET (8)
  143. +       RCODE = NOTAUTH (9)
  144. +       RCODE = NOTZONE (10)
  145. +       Opcode = UPDATE (5)
  146. + 
  147. + 2 - Update Message Format
  148. + 
  149. +    The DNS Message Format is defined by [RFC1035 4.1].  Some extensions
  150. +    are necessary (for example, more error codes are possible under
  151. +    UPDATE than under QUERY) and some fields must be overloaded (see
  152. +    description of CLASS fields below).
  153. + 
  154. +    The overall format of an UPDATE message is, following [ibid]:
  155. + 
  156. +       +---------------------+
  157. +       |        Header       |
  158. +       +---------------------+
  159. +       |         Zone        | specifies the zone to be updated
  160. +       +---------------------+
  161. +       |     Prerequisite    | RRs or RRsets which must (not) preexist
  162. +       +---------------------+
  163. +       |        Update       | RRs or RRsets to be added or deleted
  164. +       +---------------------+
  165. +       |   Additional Data   | additional data
  166. +       +---------------------+
  167. + 
  168. + 
  169. + 
  170. + 
  171. + 
  172. + 
  173. + 
  174. + 
  175. + 
  176. + 
  177. + Vixie, et. al.              Standards Track                     [Page 3]
  178. + 
  179. + RFC 2136                       DNS Update                     April 1997
  180. + 
  181. + 
  182. +    The Header Section specifies that this message is an UPDATE, and
  183. +    describes the size of the other sections.  The Zone Section names the
  184. +    zone that is to be updated by this message.  The Prerequisite Section
  185. +    specifies the starting invariants (in terms of zone content) required
  186. +    for this update.  The Update Section contains the edits to be made,
  187. +    and the Additional Data Section contains data which may be necessary
  188. +    to complete, but is not part of, this update.
  189. + 
  190. +    2.1 - Transport Issues
  191. + 
  192. +    An update transaction may be carried in a UDP datagram, if the
  193. +    request fits, or in a TCP connection (at the discretion of the
  194. +    requestor).  When TCP is used, the message is in the format described
  195. +    in [RFC1035 4.2.2].
  196. + 
  197. +    2.2 - Message Header
  198. + 
  199. +    The header of the DNS Message Format is defined by [RFC 1035 4.1].
  200. +    Not all opcodes define the same set of flag bits, though as a
  201. +    practical matter most of the bits defined for QUERY (in [ibid]) are
  202. +    identically defined by the other opcodes.  UPDATE uses only one flag
  203. +    bit (QR).
  204. + 
  205. +    The DNS Message Format specifies record counts for its four sections
  206. +    (Question, Answer, Authority, and Additional).  UPDATE uses the same
  207. +    fields, and the same section formats, but the naming and use of these
  208. +    sections differs as shown in the following modified header, after
  209. +    [RFC1035 4.1.1]:
  210. + 
  211. +                                       1  1  1  1  1  1
  212. +         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  213. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  214. +       |                      ID                       |
  215. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  216. +       |QR|   Opcode  |          Z         |   RCODE   |
  217. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  218. +       |                    ZOCOUNT                    |
  219. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  220. +       |                    PRCOUNT                    |
  221. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  222. +       |                    UPCOUNT                    |
  223. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  224. +       |                    ADCOUNT                    |
  225. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  226. + 
  227. + 
  228. + 
  229. + 
  230. + 
  231. + 
  232. + 
  233. + Vixie, et. al.              Standards Track                     [Page 4]
  234. + 
  235. + RFC 2136                       DNS Update                     April 1997
  236. + 
  237. + 
  238. +    These fields are used as follows:
  239. + 
  240. +    ID      A 16-bit identifier assigned by the entity that generates any
  241. +            kind of request.  This identifier is copied in the
  242. +            corresponding reply and can be used by the requestor to match
  243. +            replies to outstanding requests, or by the server to detect
  244. +            duplicated requests from some requestor.
  245. + 
  246. +    QR      A one bit field that specifies whether this message is a
  247. +            request (0), or a response (1).
  248. + 
  249. +    Opcode  A four bit field that specifies the kind of request in this
  250. +            message.  This value is set by the originator of a request
  251. +            and copied into the response.  The Opcode value that
  252. +            identifies an UPDATE message is five (5).
  253. + 
  254. +    Z       Reserved for future use.  Should be zero (0) in all requests
  255. +            and responses.  A non-zero Z field should be ignored by
  256. +            implementations of this specification.
  257. + 
  258. +    RCODE   Response code - this four bit field is undefined in requests
  259. +            and set in responses.  The values and meanings of this field
  260. +            within responses are as follows:
  261. + 
  262. +               Mneumonic   Value   Description
  263. +               ------------------------------------------------------------
  264. +               NOERROR     0       No error condition.
  265. +               FORMERR     1       The name server was unable to interpret
  266. +                                   the request due to a format error.
  267. +               SERVFAIL    2       The name server encountered an internal
  268. +                                   failure while processing this request,
  269. +                                   for example an operating system error
  270. +                                   or a forwarding timeout.
  271. +               NXDOMAIN    3       Some name that ought to exist,
  272. +                                   does not exist.
  273. +               NOTIMP      4       The name server does not support
  274. +                                   the specified Opcode.
  275. +               REFUSED     5       The name server refuses to perform the
  276. +                                   specified operation for policy or
  277. +                                   security reasons.
  278. +               YXDOMAIN    6       Some name that ought not to exist,
  279. +                                   does exist.
  280. +               YXRRSET     7       Some RRset that ought not to exist,
  281. +                                   does exist.
  282. +               NXRRSET     8       Some RRset that ought to exist,
  283. +                                   does not exist.
  284. + 
  285. + 
  286. + 
  287. + 
  288. + 
  289. + Vixie, et. al.              Standards Track                     [Page 5]
  290. + 
  291. + RFC 2136                       DNS Update                     April 1997
  292. + 
  293. + 
  294. +               NOTAUTH     9       The server is not authoritative for
  295. +                                   the zone named in the Zone Section.
  296. +               NOTZONE     10      A name used in the Prerequisite or
  297. +                                   Update Section is not within the
  298. +                                   zone denoted by the Zone Section.
  299. + 
  300. +    ZOCOUNT The number of RRs in the Zone Section.
  301. + 
  302. +    PRCOUNT The number of RRs in the Prerequisite Section.
  303. + 
  304. +    UPCOUNT The number of RRs in the Update Section.
  305. + 
  306. +    ADCOUNT The number of RRs in the Additional Data Section.
  307. + 
  308. +    2.3 - Zone Section
  309. + 
  310. +    The Zone Section has the same format as that specified in [RFC1035
  311. +    4.1.2], with the fields redefined as follows:
  312. + 
  313. +                                       1  1  1  1  1  1
  314. +         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  315. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  316. +       |                                               |
  317. +       /                     ZNAME                     /
  318. +       /                                               /
  319. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  320. +       |                     ZTYPE                     |
  321. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  322. +       |                     ZCLASS                    |
  323. +       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  324. + 
  325. +    UPDATE uses this section to denote the zone of the records being
  326. +    updated.  All records to be updated must be in the same zone, and
  327. +    therefore the Zone Section is allowed to contain exactly one record.
  328. +    The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
  329. +    the zone's class.
  330. + 
  331. +    2.4 - Prerequisite Section
  332. + 
  333. +    This section contains a set of RRset prerequisites which must be
  334. +    satisfied at the time the UPDATE packet is received by the primary
  335. +    master server.  The format of this section is as specified by
  336. +    [RFC1035 4.1.3].  There are five possible sets of semantics that can
  337. +    be expressed here, summarized as follows and then explained below.
  338. + 
  339. +       (1)  RRset exists (value independent).  At least one RR with a
  340. +            specified NAME and TYPE (in the zone and class specified by
  341. +            the Zone Section) must exist.
  342. + 
  343. + 
  344. + 
  345. + Vixie, et. al.              Standards Track                     [Page 6]
  346. + 
  347. + RFC 2136                       DNS Update                     April 1997
  348. + 
  349. + 
  350. +       (2)  RRset exists (value dependent).  A set of RRs with a
  351. +            specified NAME and TYPE exists and has the same members
  352. +            with the same RDATAs as the RRset specified here in this
  353. +            Section.
  354. + 
  355. +       (3)  RRset does not exist.  No RRs with a specified NAME and TYPE
  356. +           (in the zone and class denoted by the Zone Section) can exist.
  357. + 
  358. +       (4)  Name is in use.  At least one RR with a specified NAME (in
  359. +            the zone and class specified by the Zone Section) must exist.
  360. +            Note that this prerequisite is NOT satisfied by empty
  361. +            nonterminals.
  362. + 
  363. +       (5)  Name is not in use.  No RR of any type is owned by a
  364. +            specified NAME.  Note that this prerequisite IS satisfied by
  365. +            empty nonterminals.
  366. + 
  367. +    The syntax of these is as follows:
  368. + 
  369. +    2.4.1 - RRset Exists (Value Independent)
  370. + 
  371. +    At least one RR with a specified NAME and TYPE (in the zone and class
  372. +    specified in the Zone Section) must exist.
  373. + 
  374. +    For this prerequisite, a requestor adds to the section a single RR
  375. +    whose NAME and TYPE are equal to that of the zone RRset whose
  376. +    existence is required.  RDLENGTH is zero and RDATA is therefore
  377. +    empty.  CLASS must be specified as ANY to differentiate this
  378. +    condition from that of an actual RR whose RDLENGTH is naturally zero
  379. +    (0) (e.g., NULL).  TTL is specified as zero (0).
  380. + 
  381. +    2.4.2 - RRset Exists (Value Dependent)
  382. + 
  383. +    A set of RRs with a specified NAME and TYPE exists and has the same
  384. +    members with the same RDATAs as the RRset specified here in this
  385. +    section.  While RRset ordering is undefined and therefore not
  386. +    significant to this comparison, the sets be identical in their
  387. +    extent.
  388. + 
  389. +    For this prerequisite, a requestor adds to the section an entire
  390. +    RRset whose preexistence is required.  NAME and TYPE are that of the
  391. +    RRset being denoted.  CLASS is that of the zone.  TTL must be
  392. +    specified as zero (0) and is ignored when comparing RRsets for
  393. +    identity.
  394. + 
  395. + 
  396. + 
  397. + 
  398. + 
  399. + 
  400. + 
  401. + Vixie, et. al.              Standards Track                     [Page 7]
  402. + 
  403. + RFC 2136                       DNS Update                     April 1997
  404. + 
  405. + 
  406. +    2.4.3 - RRset Does Not Exist
  407. + 
  408. +    No RRs with a specified NAME and TYPE (in the zone and class denoted
  409. +    by the Zone Section) can exist.
  410. + 
  411. +    For this prerequisite, a requestor adds to the section a single RR
  412. +    whose NAME and TYPE are equal to that of the RRset whose nonexistence
  413. +    is required.  The RDLENGTH of this record is zero (0), and RDATA
  414. +    field is therefore empty.  CLASS must be specified as NONE in order
  415. +    to distinguish this condition from a valid RR whose RDLENGTH is
  416. +    naturally zero (0) (for example, the NULL RR).  TTL must be specified
  417. +    as zero (0).
  418. + 
  419. +    2.4.4 - Name Is In Use
  420. + 
  421. +    Name is in use.  At least one RR with a specified NAME (in the zone
  422. +    and class specified by the Zone Section) must exist.  Note that this
  423. +    prerequisite is NOT satisfied by empty nonterminals.
  424. + 
  425. +    For this prerequisite, a requestor adds to the section a single RR
  426. +    whose NAME is equal to that of the name whose ownership of an RR is
  427. +    required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS must
  428. +    be specified as ANY to differentiate this condition from that of an
  429. +    actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL).  TYPE
  430. +    must be specified as ANY to differentiate this case from that of an
  431. +    RRset existence test.  TTL is specified as zero (0).
  432. + 
  433. +    2.4.5 - Name Is Not In Use
  434. + 
  435. +    Name is not in use.  No RR of any type is owned by a specified NAME.
  436. +    Note that this prerequisite IS satisfied by empty nonterminals.
  437. + 
  438. +    For this prerequisite, a requestor adds to the section a single RR
  439. +    whose NAME is equal to that of the name whose nonownership of any RRs
  440. +    is required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS
  441. +    must be specified as NONE.  TYPE must be specified as ANY.  TTL must
  442. +    be specified as zero (0).
  443. + 
  444. +    2.5 - Update Section
  445. + 
  446. +    This section contains RRs to be added to or deleted from the zone.
  447. +    The format of this section is as specified by [RFC1035 4.1.3].  There
  448. +    are four possible sets of semantics, summarized below and with
  449. +    details to follow.
  450. + 
  451. + 
  452. + 
  453. + 
  454. + 
  455. + 
  456. + 
  457. + Vixie, et. al.              Standards Track                     [Page 8]
  458. + 
  459. + RFC 2136                       DNS Update                     April 1997
  460. + 
  461. + 
  462. +       (1) Add RRs to an RRset.
  463. +       (2) Delete an RRset.
  464. +       (3) Delete all RRsets from a name.
  465. +       (4) Delete an RR from an RRset.
  466. + 
  467. +    The syntax of these is as follows:
  468. + 
  469. +    2.5.1 - Add To An RRset
  470. + 
  471. +    RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
  472. +    and RDATA are those being added, and CLASS is the same as the zone
  473. +    class.  Any duplicate RRs will be silently ignored by the primary
  474. +    master.
  475. + 
  476. +    2.5.2 - Delete An RRset
  477. + 
  478. +    One RR is added to the Update Section whose NAME and TYPE are those
  479. +    of the RRset to be deleted.  TTL must be specified as zero (0) and is
  480. +    otherwise not used by the primary master.  CLASS must be specified as
  481. +    ANY.  RDLENGTH must be zero (0) and RDATA must therefore be empty.
  482. +    If no such RRset exists, then this Update RR will be silently ignored
  483. +    by the primary master.
  484. + 
  485. +    2.5.3 - Delete All RRsets From A Name
  486. + 
  487. +    One RR is added to the Update Section whose NAME is that of the name
  488. +    to be cleansed of RRsets.  TYPE must be specified as ANY.  TTL must
  489. +    be specified as zero (0) and is otherwise not used by the primary
  490. +    master.  CLASS must be specified as ANY.  RDLENGTH must be zero (0)
  491. +    and RDATA must therefore be empty.  If no such RRsets exist, then
  492. +    this Update RR will be silently ignored by the primary master.
  493. + 
  494. +    2.5.4 - Delete An RR From An RRset
  495. + 
  496. +    RRs to be deleted are added to the Update Section.  The NAME, TYPE,
  497. +    RDLENGTH and RDATA must match the RR being deleted.  TTL must be
  498. +    specified as zero (0) and will otherwise be ignored by the primary
  499. +    master.  CLASS must be specified as NONE to distinguish this from an
  500. +    RR addition.  If no such RRs exist, then this Update RR will be
  501. +    silently ignored by the primary master.
  502. + 
  503. + 
  504. + 
  505. + 
  506. + 
  507. + 
  508. + 
  509. + 
  510. + 
  511. + 
  512. + 
  513. + Vixie, et. al.              Standards Track                     [Page 9]
  514. + 
  515. + RFC 2136                       DNS Update                     April 1997
  516. + 
  517. + 
  518. +    2.6 - Additional Data Section
  519. + 
  520. +    This section contains RRs which are related to the update itself, or
  521. +    to new RRs being added by the update.  For example, out of zone glue
  522. +    (A RRs referred to by new NS RRs) should be presented here.  The
  523. +    server can use or ignore out of zone glue, at the discretion of the
  524. +    server implementor.  The format of this section is as specified by
  525. +    [RFC1035 4.1.3].
  526. + 
  527. + 3 - Server Behavior
  528. + 
  529. +    A server, upon receiving an UPDATE request, will signal NOTIMP to the
  530. +    requestor if the UPDATE opcode is not recognized or if it is
  531. +    recognized but has not been implemented.  Otherwise, processing
  532. +    continues as follows.
  533. + 
  534. +    3.1 - Process Zone Section
  535. + 
  536. +    3.1.1. The Zone Section is checked to see that there is exactly one
  537. +    RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
  538. +    requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
  539. +    so named is one of this server's authority zones, else signal NOTAUTH
  540. +    to the requestor.  If the server is a zone slave, the request will be
  541. +    forwarded toward the primary master.
  542. + 
  543. +    3.1.2 - Pseudocode For Zone Section Processing
  544. + 
  545. +       if (zcount != 1 || ztype != SOA)
  546. +            return (FORMERR)
  547. +       if (zone_type(zname, zclass) == SLAVE)
  548. +            return forward()
  549. +       if (zone_type(zname, zclass) == MASTER)
  550. +            return update()
  551. +       return (NOTAUTH)
  552. + 
  553. +    Sections 3.2 through 3.8 describe the primary master's behaviour,
  554. +    whereas Section 6 describes a forwarder's behaviour.
  555. + 
  556. +    3.2 - Process Prerequisite Section
  557. + 
  558. +    Next, the Prerequisite Section is checked to see that all
  559. +    prerequisites are satisfied by the current state of the zone.  Using
  560. +    the definitions expressed in Section 1.2, if any RR's NAME is not
  561. +    within the zone specified in the Zone Section, signal NOTZONE to the
  562. +    requestor.
  563. + 
  564. + 
  565. + 
  566. + 
  567. + 
  568. + 
  569. + Vixie, et. al.              Standards Track                    [Page 10]
  570. + 
  571. + RFC 2136                       DNS Update                     April 1997
  572. + 
  573. + 
  574. +    3.2.1. For RRs in this section whose CLASS is ANY, test to see that
  575. +    TTL and RDLENGTH are both zero (0), else signal FORMERR to the
  576. +    requestor.  If TYPE is ANY, test to see that there is at least one RR
  577. +    in the zone whose NAME is the same as that of the Prerequisite RR,
  578. +    else signal NXDOMAIN to the requestor.  If TYPE is not ANY, test to
  579. +    see that there is at least one RR in the zone whose NAME and TYPE are
  580. +    the same as that of the Prerequisite RR, else signal NXRRSET to the
  581. +    requestor.
  582. + 
  583. +    3.2.2. For RRs in this section whose CLASS is NONE, test to see that
  584. +    the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
  585. +    requestor.  If the TYPE is ANY, test to see that there are no RRs in
  586. +    the zone whose NAME is the same as that of the Prerequisite RR, else
  587. +    signal YXDOMAIN to the requestor.  If the TYPE is not ANY, test to
  588. +    see that there are no RRs in the zone whose NAME and TYPE are the
  589. +    same as that of the Prerequisite RR, else signal YXRRSET to the
  590. +    requestor.
  591. + 
  592. +    3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
  593. +    test to see that the TTL is zero (0), else signal FORMERR to the
  594. +    requestor.  Then, build an RRset for each unique <NAME,TYPE> and
  595. +    compare each resulting RRset for set equality (same members, no more,
  596. +    no less) with RRsets in the zone.  If any Prerequisite RRset is not
  597. +    entirely and exactly matched by a zone RRset, signal NXRRSET to the
  598. +    requestor.  If any RR in this section has a CLASS other than ZCLASS
  599. +    or NONE or ANY, signal FORMERR to the requestor.
  600. + 
  601. +    3.2.4 - Table Of Metavalues Used In Prerequisite Section
  602. + 
  603. +    CLASS    TYPE     RDATA    Meaning
  604. +    ------------------------------------------------------------
  605. +    ANY      ANY      empty    Name is in use
  606. +    ANY      rrset    empty    RRset exists (value independent)
  607. +    NONE     ANY      empty    Name is not in use
  608. +    NONE     rrset    empty    RRset does not exist
  609. +    zone     rrset    rr       RRset exists (value dependent)
  610. + 
  611. + 
  612. + 
  613. + 
  614. + 
  615. + 
  616. + 
  617. + 
  618. + 
  619. + 
  620. + 
  621. + 
  622. + 
  623. + 
  624. + 
  625. + Vixie, et. al.              Standards Track                    [Page 11]
  626. + 
  627. + RFC 2136                       DNS Update                     April 1997
  628. + 
  629. + 
  630. +    3.2.5 - Pseudocode for Prerequisite Section Processing
  631. + 
  632. +       for rr in prerequisites
  633. +            if (rr.ttl != 0)
  634. +                 return (FORMERR)
  635. +            if (zone_of(rr.name) != ZNAME)
  636. +                 return (NOTZONE);
  637. +            if (rr.class == ANY)
  638. +                 if (rr.rdlength != 0)
  639. +                      return (FORMERR)
  640. +                 if (rr.type == ANY)
  641. +                      if (!zone_name<rr.name>)
  642. +                           return (NXDOMAIN)
  643. +                 else
  644. +                      if (!zone_rrset<rr.name, rr.type>)
  645. +                           return (NXRRSET)
  646. +            if (rr.class == NONE)
  647. +                 if (rr.rdlength != 0)
  648. +                      return (FORMERR)
  649. +                 if (rr.type == ANY)
  650. +                      if (zone_name<rr.name>)
  651. +                           return (YXDOMAIN)
  652. +                 else
  653. +                      if (zone_rrset<rr.name, rr.type>)
  654. +                           return (YXRRSET)
  655. +            if (rr.class == zclass)
  656. +                 temp<rr.name, rr.type> += rr
  657. +            else
  658. +                 return (FORMERR)
  659. + 
  660. +       for rrset in temp
  661. +            if (zone_rrset<rrset.name, rrset.type> != rrset)
  662. +                 return (NXRRSET)
  663. + 
  664. +    3.3 - Check Requestor's Permissions
  665. + 
  666. +    3.3.1. Next, the requestor's permission to update the RRs named in
  667. +    the Update Section may be tested in an implementation dependent
  668. +    fashion or using mechanisms specified in a subsequent Secure DNS
  669. +    Update protocol.  If the requestor does not have permission to
  670. +    perform these updates, the server may write a warning message in its
  671. +    operations log, and may either signal REFUSED to the requestor, or
  672. +    ignore the permission problem and proceed with the update.
  673. + 
  674. + 
  675. + 
  676. + 
  677. + 
  678. + 
  679. + 
  680. + 
  681. + Vixie, et. al.              Standards Track                    [Page 12]
  682. + 
  683. + RFC 2136                       DNS Update                     April 1997
  684. + 
  685. + 
  686. +    3.3.2. While the exact processing is implementation defined, if these
  687. +    verification activities are to be performed, this is the point in the
  688. +    server's processing where such performance should take place, since
  689. +    if a REFUSED condition is encountered after an update has been
  690. +    partially applied, it will be necessary to undo the partial update
  691. +    and restore the zone to its original state before answering the
  692. +    requestor.
  693. + 
  694. +    3.3.3 - Pseudocode for Permission Checking
  695. + 
  696. +       if (security policy exists)
  697. +            if (this update is not permitted)
  698. +                 if (local option)
  699. +                      log a message about permission problem
  700. +                 if (local option)
  701. +                      return (REFUSED)
  702. + 
  703. +    3.4 - Process Update Section
  704. + 
  705. +    Next, the Update Section is processed as follows.
  706. + 
  707. +    3.4.1 - Prescan
  708. + 
  709. +    The Update Section is parsed into RRs and each RR's CLASS is checked
  710. +    to see if it is ANY, NONE, or the same as the Zone Class, else signal
  711. +    a FORMERR to the requestor.  Using the definitions in Section 1.2,
  712. +    each RR's NAME must be in the zone specified by the Zone Section,
  713. +    else signal NOTZONE to the requestor.
  714. + 
  715. +    3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
  716. +    ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
  717. +    unrecognized type, then signal FORMERR to the requestor.  For RRs
  718. +    whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
  719. +    else signal a FORMERR to the requestor.  For any RR whose CLASS is
  720. +    ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
  721. +    the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
  722. +    MAILB, or any other QUERY metatype besides ANY, or any unrecognized
  723. +    type, else signal FORMERR to the requestor.
  724. + 
  725. + 
  726. + 
  727. + 
  728. + 
  729. + 
  730. + 
  731. + 
  732. + 
  733. + 
  734. + 
  735. + 
  736. + 
  737. + Vixie, et. al.              Standards Track                    [Page 13]
  738. + 
  739. + RFC 2136                       DNS Update                     April 1997
  740. + 
  741. + 
  742. +    3.4.1.3 - Pseudocode For Update Section Prescan
  743. + 
  744. +       [rr] for rr in updates
  745. +            if (zone_of(rr.name) != ZNAME)
  746. +                 return (NOTZONE);
  747. +            if (rr.class == zclass)
  748. +                 if (rr.type & ANY|AXFR|MAILA|MAILB)
  749. +                      return (FORMERR)
  750. +            elsif (rr.class == ANY)
  751. +                 if (rr.ttl != 0 || rr.rdlength != 0
  752. +                     || rr.type & AXFR|MAILA|MAILB)
  753. +                      return (FORMERR)
  754. +            elsif (rr.class == NONE)
  755. +                 if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
  756. +                      return (FORMERR)
  757. +            else
  758. +                 return (FORMERR)
  759. + 
  760. +    3.4.2 - Update
  761. + 
  762. +    The Update Section is parsed into RRs and these RRs are processed in
  763. +    order.
  764. + 
  765. +    3.4.2.1. If any system failure (such as an out of memory condition,
  766. +    or a hardware error in persistent storage) occurs during the
  767. +    processing of this section, signal SERVFAIL to the requestor and undo
  768. +    all updates applied to the zone during this transaction.
  769. + 
  770. +    3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
  771. +    the zone.  In case of duplicate RDATAs (which for SOA RRs is always
  772. +    the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
  773. +    fields both match), the Zone RR is replaced by Update RR.  If the
  774. +    TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
  775. +    lower (according to [RFC1982]) than or equal to the current Zone SOA
  776. +    RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
  777. +    Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
  778. +    Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
  779. +    RR.
  780. + 
  781. +    3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
  782. +    all Zone RRs with the same NAME are deleted, unless the NAME is the
  783. +    same as ZNAME in which case only those RRs whose TYPE is other than
  784. +    SOA or NS are deleted.  For any Update RR whose CLASS is ANY and
  785. +    whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
  786. +    deleted, unless the NAME is the same as ZNAME in which case neither
  787. +    SOA or NS RRs will be deleted.
  788. + 
  789. + 
  790. + 
  791. + 
  792. + 
  793. + Vixie, et. al.              Standards Track                    [Page 14]
  794. + 
  795. + RFC 2136                       DNS Update                     April 1997
  796. + 
  797. + 
  798. +    3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
  799. +    NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
  800. +    unless the NAME is the same as ZNAME and either the TYPE is SOA or
  801. +    the TYPE is NS and the matching Zone RR is the only NS remaining in
  802. +    the RRset, in which case this Update RR is ignored.
  803. + 
  804. +    3.4.2.5. Signal NOERROR to the requestor.
  805. + 
  806. +    3.4.2.6 - Table Of Metavalues Used In Update Section
  807. + 
  808. +    CLASS    TYPE     RDATA    Meaning
  809. +    ---------------------------------------------------------
  810. +    ANY      ANY      empty    Delete all RRsets from a name
  811. +    ANY      rrset    empty    Delete an RRset
  812. +    NONE     rrset    rr       Delete an RR from an RRset
  813. +    zone     rrset    rr       Add to an RRset
  814. + 
  815. +    3.4.2.7 - Pseudocode For Update Section Processing
  816. + 
  817. +       [rr] for rr in updates
  818. +            if (rr.class == zclass)
  819. +                 if (rr.type == CNAME)
  820. +                      if (zone_rrset<rr.name, ~CNAME>)
  821. +                           next [rr]
  822. +                 elsif (zone_rrset<rr.name, CNAME>)
  823. +                      next [rr]
  824. +                 if (rr.type == SOA)
  825. +                      if (!zone_rrset<rr.name, SOA> ||
  826. +                          zone_rr<rr.name, SOA>.serial > rr.soa.serial)
  827. +                           next [rr]
  828. +                 for zrr in zone_rrset<rr.name, rr.type>
  829. +                      if (rr.type == CNAME || rr.type == SOA ||
  830. +                          (rr.type == WKS && rr.proto == zrr.proto &&
  831. +                           rr.address == zrr.address) ||
  832. +                          rr.rdata == zrr.rdata)
  833. +                           zrr = rr
  834. +                           next [rr]
  835. +                 zone_rrset<rr.name, rr.type> += rr
  836. +            elsif (rr.class == ANY)
  837. +                 if (rr.type == ANY)
  838. +                      if (rr.name == zname)
  839. +                           zone_rrset<rr.name, ~(SOA|NS)> = Nil
  840. +                      else
  841. +                           zone_rrset<rr.name, *> = Nil
  842. +                 elsif (rr.name == zname &&
  843. +                        (rr.type == SOA || rr.type == NS))
  844. +                      next [rr]
  845. +                 else
  846. + 
  847. + 
  848. + 
  849. + Vixie, et. al.              Standards Track                    [Page 15]
  850. + 
  851. + RFC 2136                       DNS Update                     April 1997
  852. + 
  853. + 
  854. +                      zone_rrset<rr.name, rr.type> = Nil
  855. +            elsif (rr.class == NONE)
  856. +                 if (rr.type == SOA)
  857. +                      next [rr]
  858. +                 if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
  859. +                      next [rr]
  860. +                 zone_rr<rr.name, rr.type, rr.data> = Nil
  861. +       return (NOERROR)
  862. + 
  863. +    3.5 - Stability
  864. + 
  865. +    When a zone is modified by an UPDATE operation, the server must
  866. +    commit the change to nonvolatile storage before sending a response to
  867. +    the requestor or answering any queries or transfers for the modified
  868. +    zone.  It is reasonable for a server to store only the update records
  869. +    as long as a system reboot or power failure will cause these update
  870. +    records to be incorporated into the zone the next time the server is
  871. +    started.  It is also reasonable for the server to copy the entire
  872. +    modified zone to nonvolatile storage after each update operation,
  873. +    though this would have suboptimal performance for large zones.
  874. + 
  875. +    3.6 - Zone Identity
  876. + 
  877. +    If the zone's SOA SERIAL is changed by an update operation, that
  878. +    change must be in a positive direction (using modulo 2**32 arithmetic
  879. +    as specified by [RFC1982]).  Attempts to replace an SOA with one
  880. +    whose SERIAL is less than the current one will be silently ignored by
  881. +    the primary master server.
  882. + 
  883. +    If the zone's SOA's SERIAL is not changed as a result of an update
  884. +    operation, then the server shall increment it automatically before
  885. +    the SOA or any changed name or RR or RRset is included in any
  886. +    response or transfer.  The primary master server's implementor might
  887. +    choose to autoincrement the SOA SERIAL if any of the following events
  888. +    occurs:
  889. + 
  890. +    (1)  Each update operation.
  891. + 
  892. +    (2)  A name, RR or RRset in the zone has changed and has subsequently
  893. +         been visible to a DNS client since the unincremented SOA was
  894. +         visible to a DNS client, and the SOA is about to become visible
  895. +         to a DNS client.
  896. + 
  897. +    (3)  A configurable period of time has elapsed since the last update
  898. +         operation.  This period shall be less than or equal to one third
  899. +         of the zone refresh time, and the default shall be the lesser of
  900. +         that maximum and 300 seconds.
  901. + 
  902. + 
  903. + 
  904. + 
  905. + Vixie, et. al.              Standards Track                    [Page 16]
  906. + 
  907. + RFC 2136                       DNS Update                     April 1997
  908. + 
  909. + 
  910. +    (4)  A configurable number of updates has been applied since the last
  911. +         SOA change.  The default value for this configuration parameter
  912. +         shall be one hundred (100).
  913. + 
  914. +    It is imperative that the zone's contents and the SOA's SERIAL be
  915. +    tightly synchronized.  If the zone appears to change, the SOA must
  916. +    appear to change as well.
  917. + 
  918. +    3.7 - Atomicity
  919. + 
  920. +    During the processing of an UPDATE transaction, the server must
  921. +    ensure atomicity with respect to other (concurrent) UPDATE or QUERY
  922. +    transactions.  No two transactions can be processed concurrently if
  923. +    either depends on the final results of the other; in particular, a
  924. +    QUERY should not be able to retrieve RRsets which have been partially
  925. +    modified by a concurrent UPDATE, and an UPDATE should not be able to
  926. +    start from prerequisites that might not still hold at the completion
  927. +    of some other concurrent UPDATE.  Finally, if two UPDATE transactions
  928. +    would modify the same names, RRs or RRsets, then such UPDATE
  929. +    transactions must be serialized.
  930. + 
  931. +    3.8 - Response
  932. + 
  933. +    At the end of UPDATE processing, a response code will be known.  A
  934. +    response message is generated by copying the ID and Opcode fields
  935. +    from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
  936. +    and ADCOUNT fields and associated sections, or placing zeros (0) in
  937. +    the these "count" fields and not including any part of the original
  938. +    update.  The QR bit is set to one (1), and the response is sent back
  939. +    to the requestor.  If the requestor used UDP, then the response will
  940. +    be sent to the requestor's source UDP port.  If the requestor used
  941. +    TCP, then the response will be sent back on the requestor's open TCP
  942. +    connection.
  943. + 
  944. + 4 - Requestor Behaviour
  945. + 
  946. +    4.1. From a requestor's point of view, any authoritative server for
  947. +    the zone can appear to be able to process update requests, even
  948. +    though only the primary master server is actually able to modify the
  949. +    zone's master file.  Requestors are expected to know the name of the
  950. +    zone they intend to update and to know or be able to determine the
  951. +    name servers for that zone.
  952. + 
  953. + 
  954. + 
  955. + 
  956. + 
  957. + 
  958. + 
  959. + 
  960. + 
  961. + Vixie, et. al.              Standards Track                    [Page 17]
  962. + 
  963. + RFC 2136                       DNS Update                     April 1997
  964. + 
  965. + 
  966. +    4.2. If update ordering is desired, the requestor will need to know
  967. +    the value of the existing SOA RR.  Requestors who update the SOA RR
  968. +    must update the SOA SERIAL field in a positive direction (as defined
  969. +    by [RFC1982]) and also preserve the other SOA fields unless the
  970. +    requestor's explicit intent is to change them.  The SOA SERIAL field
  971. +    must never be set to zero (0).
  972. + 
  973. +    4.3. If the requestor has reasonable cause to believe that all of a
  974. +    zone's servers will be equally reachable, then it should arrange to
  975. +    try the primary master server (as given by the SOA MNAME field if
  976. +    matched by some NS NSDNAME) first to avoid unnecessary forwarding
  977. +    inside the slave servers.  (Note that the primary master will in some
  978. +    cases not be reachable by all requestors, due to firewalls or network
  979. +    partitioning.)
  980. + 
  981. +    4.4. Once the zone's name servers been found and possibly sorted so
  982. +    that the ones more likely to be reachable and/or support the UPDATE
  983. +    opcode are listed first, the requestor composes an UPDATE message of
  984. +    the following form and sends it to the first name server on its list:
  985. + 
  986. +       ID:                        (new)
  987. +       Opcode:                    UPDATE
  988. +       Zone zcount:               1
  989. +       Zone zname:                (zone name)
  990. +       Zone zclass:               (zone class)
  991. +       Zone ztype:                T_SOA
  992. +       Prerequisite Section:      (see previous text)
  993. +       Update Section:            (see previous text)
  994. +       Additional Data Section:   (empty)
  995. + 
  996. +    4.5. If the requestor receives a response, and the response has an
  997. +    RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
  998. +    appropriate response to its caller.
  999. + 
  1000. +    4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
  1001. +    if no response is received within an implementation dependent timeout
  1002. +    period, or if an ICMP error is received indicating that the server's
  1003. +    port is unreachable, then the requestor will delete the unusable
  1004. +    server from its internal name server list and try the next one,
  1005. +    repeating until the name server list is empty.  If the requestor runs
  1006. +    out of servers to try, an appropriate error will be returned to the
  1007. +    requestor's caller.
  1008. + 
  1009. + 
  1010. + 
  1011. + 
  1012. + 
  1013. + 
  1014. + 
  1015. + 
  1016. + 
  1017. + Vixie, et. al.              Standards Track                    [Page 18]
  1018. + 
  1019. + RFC 2136                       DNS Update                     April 1997
  1020. + 
  1021. + 
  1022. + 5 - Duplicate Detection, Ordering and Mutual Exclusion
  1023. + 
  1024. +    5.1. For correct operation, mechanisms may be needed to ensure
  1025. +    idempotence, order UPDATE requests and provide mutual exclusion.  An
  1026. +    UPDATE message or response might be delivered zero times, one time,
  1027. +    or multiple times.  Datagram duplication is of particular interest
  1028. +    since it covers the case of the so-called "replay attack" where a
  1029. +    correct request is duplicated maliciously by an intruder.
  1030. + 
  1031. +    5.2. Multiple UPDATE requests or responses in transit might be
  1032. +    delivered in any order, due to network topology changes or load
  1033. +    balancing, or to multipath forwarding graphs wherein several slave
  1034. +    servers all forward to the primary master.  In some cases, it might
  1035. +    be required that the earlier update not be applied after the later
  1036. +    update, where "earlier" and "later" are defined by an external time
  1037. +    base visible to some set of requestors, rather than by the order of
  1038. +    request receipt at the primary master.
  1039. + 
  1040. +    5.3. A requestor can ensure transaction idempotence by explicitly
  1041. +    deleting some "marker RR" (rather than deleting the RRset of which it
  1042. +    is a part) and then adding a new "marker RR" with a different RDATA
  1043. +    field.  The Prerequisite Section should specify that the original
  1044. +    "marker RR" must be present in order for this UPDATE message to be
  1045. +    accepted by the server.
  1046. + 
  1047. +    5.4. If the request is duplicated by a network error, all duplicate
  1048. +    requests will fail since only the first will find the original
  1049. +    "marker RR" present and having its known previous value.  The
  1050. +    decisions of whether to use such a "marker RR" and what RR to use are
  1051. +    left up to the application programmer, though one obvious choice is
  1052. +    the zone's SOA RR as described below.
  1053. + 
  1054. +    5.5. Requestors can ensure update ordering by externally
  1055. +    synchronizing their use of successive values of the "marker RR."
  1056. +    Mutual exclusion can be addressed as a degenerate case, in that a
  1057. +    single succession of the "marker RR" is all that is needed.
  1058. + 
  1059. +    5.6. A special case where update ordering and datagram duplication
  1060. +    intersect is when an RR validly changes to some new value and then
  1061. +    back to its previous value.  Without a "marker RR" as described
  1062. +    above, this sequence of updates can leave the zone in an undefined
  1063. +    state if datagrams are duplicated.
  1064. + 
  1065. +    5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
  1066. +    a requestor could first retrieve the SOA RR, and build an UPDATE
  1067. +    message one of whose prerequisites was the old SOA RR.  It would then
  1068. +    specify updates that would delete this SOA RR and add a new one with
  1069. +    an incremented SOA SERIAL, along with whatever actual prerequisites
  1070. + 
  1071. + 
  1072. + 
  1073. + Vixie, et. al.              Standards Track                    [Page 19]
  1074. + 
  1075. + RFC 2136                       DNS Update                     April 1997
  1076. + 
  1077. + 
  1078. +    and updates were the object of the transaction.  If the transaction
  1079. +    succeeds, the requestor knows that the RRs being changed were not
  1080. +    otherwise altered by any other requestor.
  1081. + 
  1082. + 6 - Forwarding
  1083. + 
  1084. +    When a zone slave forwards an UPDATE message upward toward the zone's
  1085. +    primary master server, it must allocate a new ID and prepare to enter
  1086. +    the role of "forwarding server," which is a requestor with respect to
  1087. +    the forward server.
  1088. + 
  1089. +    6.1. The set of forward servers will be same as the set of servers
  1090. +    this zone slave would use as the source of AXFR or IXFR data.  So,
  1091. +    while the original requestor might have used the zone's NS RRset to
  1092. +    locate its update server, a forwarder always forwards toward its
  1093. +    designated zone master servers.
  1094. + 
  1095. +    6.2. If the original requestor used TCP, then the TCP connection from
  1096. +    the requestor is still open and the forwarder must use TCP to forward
  1097. +    the message.  If the original requestor used UDP, the forwarder may
  1098. +    use either UDP or TCP to forward the message, at the whim of the
  1099. +    implementor.
  1100. + 
  1101. +    6.3. It is reasonable for forward servers to be forwarders
  1102. +    themselves, if the AXFR dependency graph being followed is a deep one
  1103. +    involving firewalls and multiple connectivity realms.  In most cases
  1104. +    the AXFR dependency graph will be shallow and the forward server will
  1105. +    be the primary master server.
  1106. + 
  1107. +    6.4. The forwarder will not respond to its requestor until it
  1108. +    receives a response from its forward server.  UPDATE transactions
  1109. +    involving forwarders are therefore time synchronized with respect to
  1110. +    the original requestor and the primary master server.
  1111. + 
  1112. +    6.5. When there are multiple possible sources of AXFR data and
  1113. +    therefore multiple possible forward servers, a forwarder will use the
  1114. +    same fallback strategy with respect to connectivity or timeout errors
  1115. +    that it would use when performing an AXFR.  This is implementation
  1116. +    dependent.
  1117. + 
  1118. +    6.6. When a forwarder receives a response from a forward server, it
  1119. +    copies this response into a new response message, assigns its
  1120. +    requestor's ID to that message, and sends the response back to the
  1121. +    requestor.
  1122. + 
  1123. + 
  1124. + 
  1125. + 
  1126. + 
  1127. + 
  1128. + 
  1129. + Vixie, et. al.              Standards Track                    [Page 20]
  1130. + 
  1131. + RFC 2136                       DNS Update                     April 1997
  1132. + 
  1133. + 
  1134. + 7 - Design, Implementation, Operation, and Protocol Notes
  1135. + 
  1136. +    Some of the principles which guided the design of this UPDATE
  1137. +    specification are as follows.  Note that these are not part of the
  1138. +    formal specification and any disagreement between this section and
  1139. +    any other section of this document should be resolved in favour of
  1140. +    the other section.
  1141. + 
  1142. +    7.1. Using metavalues for CLASS is possible only because all RRs in
  1143. +    the packet are assumed to be in the same zone, and CLASS is an
  1144. +    attribute of a zone rather than of an RRset.  (It is for this reason
  1145. +    that the Zone Section is not optional.)
  1146. + 
  1147. +    7.2. Since there are no data-present or data-absent errors possible
  1148. +    from processing the Update Section, any necessary data-present and
  1149. +    data- absent dependencies should be specified in the Prerequisite
  1150. +    Section.
  1151. + 
  1152. +    7.3. The Additional Data Section can be used to supply a server with
  1153. +    out of zone glue that will be needed in referrals.  For example, if
  1154. +    adding a new NS RR to HOME.VIX.COM specifying a nameserver called
  1155. +    NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
  1156. +    Data Section.  Servers can use this information or ignore it, at the
  1157. +    discretion of the implementor.  We discourage caching this
  1158. +    information for use in subsequent DNS responses.
  1159. + 
  1160. +    7.4. The Additional Data Section might be used if some of the RRs
  1161. +    later needed for Secure DNS Update are not actually zone updates, but
  1162. +    rather ancillary keys or signatures not intended to be stored in the
  1163. +    zone (as an update would be), yet necessary for validating the update
  1164. +    operation.
  1165. + 
  1166. +    7.5. It is expected that in the absence of Secure DNS Update, a
  1167. +    server will only accept updates if they come from a source address
  1168. +    that has been statically configured in the server's description of a
  1169. +    primary master zone.  DHCP servers would be likely candidates for
  1170. +    inclusion in this statically configured list.
  1171. + 
  1172. +    7.6. It is not possible to create a zone using this protocol, since
  1173. +    there is no provision for a slave server to be told who its master
  1174. +    servers are.  It is expected that this protocol will be extended in
  1175. +    the future to cover this case.  Therefore, at this time, the addition
  1176. +    of SOA RRs is unsupported.  For similar reasons, deletion of SOA RRs
  1177. +    is also unsupported.
  1178. + 
  1179. + 
  1180. + 
  1181. + 
  1182. + 
  1183. + 
  1184. + 
  1185. + Vixie, et. al.              Standards Track                    [Page 21]
  1186. + 
  1187. + RFC 2136                       DNS Update                     April 1997
  1188. + 
  1189. + 
  1190. +    7.7. The prerequisite for specifying that a name own at least one RR
  1191. +    differs semantically from QUERY, in that QUERY would return
  1192. +    <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
  1193. +    this name, while UPDATE's prerequisite condition [Section 2.4.4]
  1194. +    would NOT be satisfied.
  1195. + 
  1196. +    7.8. It is possible for a UDP response to be lost in transit and for
  1197. +    a request to be retried due to a timeout condition.  In this case an
  1198. +    UPDATE that was successful the first time it was received by the
  1199. +    primary master might ultimately appear to have failed when the
  1200. +    response to a duplicate request is finally received by the requestor.
  1201. +    (This is because the original prerequisites may no longer be
  1202. +    satisfied after the update has been applied.)  For this reason,
  1203. +    requestors who require an accurate response code must use TCP.
  1204. + 
  1205. +    7.9. Because a requestor who requires an accurate response code will
  1206. +    initiate their UPDATE transaction using TCP, a forwarder who receives
  1207. +    a request via TCP must forward it using TCP.
  1208. + 
  1209. +    7.10. Deferral of SOA SERIAL autoincrements is made possible so that
  1210. +    serial numbers can be conserved and wraparound at 2**32 can be made
  1211. +    an infrequent occurance.  Visible (to DNS clients) SOA SERIALs need
  1212. +    to differ if the zone differs.  Note that the Authority Section SOA
  1213. +    in a QUERY response is a form of visibility, for the purposes of this
  1214. +    prerequisite.
  1215. + 
  1216. +    7.11. A zone's SOA SERIAL should never be set to zero (0) due to
  1217. +    interoperability problems with some older but widely installed
  1218. +    implementations of DNS.  When incrementing an SOA SERIAL, if the
  1219. +    result of the increment is zero (0) (as will be true when wrapping
  1220. +    around 2**32), it is necessary to increment it again or set it to one
  1221. +    (1).  See [RFC1982] for more detail on this subject.
  1222. + 
  1223. +    7.12. Due to the TTL minimalization necessary when caching an RRset,
  1224. +    it is recommended that all TTLs in an RRset be set to the same value.
  1225. +    While the DNS Message Format permits variant TTLs to exist in the
  1226. +    same RRset, and this variance can exist inside a zone, such variance
  1227. +    will have counterintuitive results and its use is discouraged.
  1228. + 
  1229. +    7.13. Zone cut management presents some obscure corner cases to the
  1230. +    add and delete operations in the Update Section.  It is possible to
  1231. +    delete an NS RR as long as it is not the last NS RR at the root of a
  1232. +    zone.  If deleting all RRs from a name, SOA and NS RRs at the root of
  1233. +    a zone are unaffected.  If deleting RRsets, it is not possible to
  1234. +    delete either SOA or NS RRsets at the top of a zone.  An attempt to
  1235. +    add an SOA will be treated as a replace operation if an SOA already
  1236. +    exists, or as a no-op if the SOA would be new.
  1237. + 
  1238. + 
  1239. + 
  1240. + 
  1241. + Vixie, et. al.              Standards Track                    [Page 22]
  1242. + 
  1243. + RFC 2136                       DNS Update                     April 1997
  1244. + 
  1245. + 
  1246. +    7.14. No semantic checking is required in the primary master server
  1247. +    when adding new RRs.  Therefore a requestor can cause CNAME or NS or
  1248. +    any other kind of RR to be added even if their target name does not
  1249. +    exist or does not have the proper RRsets to make the original RR
  1250. +    useful.  Primary master servers that DO implement this kind of
  1251. +    checking should take great care to avoid out-of-zone dependencies
  1252. +    (whose veracity cannot be authoritatively checked) and should
  1253. +    implement all such checking during the prescan phase.
  1254. + 
  1255. +    7.15. Nonterminal or wildcard CNAMEs are not well specified by
  1256. +    [RFC1035] and their use will probably lead to unpredictable results.
  1257. +    Their use is discouraged.
  1258. + 
  1259. +    7.16. Empty nonterminals (nodes with children but no RRs of their
  1260. +    own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response
  1261. +    to a query of any type for that name.  There is no provision for
  1262. +    empty terminal nodes -- so if all RRs of a terminal node are deleted,
  1263. +    the name is no longer in use, and queries of any type for that name
  1264. +    will result in an NXDOMAIN response.
  1265. + 
  1266. +    7.17. In a deep AXFR dependency graph, it has not historically been
  1267. +    an error for slaves to depend mutually upon each other.  This
  1268. +    configuration has been used to enable a zone to flow from the primary
  1269. +    master to all slaves even though not all slaves have continuous
  1270. +    connectivity to the primary master.  UPDATE's use of the AXFR
  1271. +    dependency graph for forwarding prohibits this kind of dependency
  1272. +    loop, since UPDATE forwarding has no loop detection analagous to the
  1273. +    SOA SERIAL pretest used by AXFR.
  1274. + 
  1275. +    7.18. Previously existing names which are occluded by a new zone cut
  1276. +    are still considered part of the parent zone, for the purposes of
  1277. +    zone transfers, even though queries for such names will be referred
  1278. +    to the new subzone's servers.  If a zone cut is removed, all parent
  1279. +    zone names that were occluded by it will again become visible to
  1280. +    queries.  (This is a clarification of [RFC1034].)
  1281. + 
  1282. +    7.19. If a server is authoritative for both a zone and its child,
  1283. +    then queries for names at the zone cut between them will be answered
  1284. +    authoritatively using only data from the child zone.  (This is a
  1285. +    clarification of [RFC1034].)
  1286. + 
  1287. + 
  1288. + 
  1289. + 
  1290. + 
  1291. + 
  1292. + 
  1293. + 
  1294. + 
  1295. + 
  1296. + 
  1297. + Vixie, et. al.              Standards Track                    [Page 23]
  1298. + 
  1299. + RFC 2136                       DNS Update                     April 1997
  1300. + 
  1301. + 
  1302. +    7.20. Update ordering using the SOA RR is problematic since there is
  1303. +    no way to know which of a zone's NS RRs represents the primary
  1304. +    master, and the zone slaves can be out of date if their SOA.REFRESH
  1305. +    timers have not elapsed since the last time the zone was changed on
  1306. +    the primary master.  We recommend that a zone needing ordered updates
  1307. +    use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see
  1308. +    [RFC1995]), and that a client receiving a prerequisite error while
  1309. +    attempting an ordered update simply retry after a random delay period
  1310. +    to allow the zone to settle.
  1311. + 
  1312. + 8 - Security Considerations
  1313. + 
  1314. +    8.1. In the absence of [RFC2137] or equivilent technology, the
  1315. +    protocol described by this document makes it possible for anyone who
  1316. +    can reach an authoritative name server to alter the contents of any
  1317. +    zones on that server.  This is a serious increase in vulnerability
  1318. +    from the current technology.  Therefore it is very strongly
  1319. +    recommended that the protocols described in this document not be used
  1320. +    without [RFC2137] or other equivalently strong security measures,
  1321. +    e.g. IPsec.
  1322. + 
  1323. +    8.2. A denial of service attack can be launched by flooding an update
  1324. +    forwarder with TCP sessions containing updates that the primary
  1325. +    master server will ultimately refuse due to permission problems.
  1326. +    This arises due to the requirement that an update forwarder receiving
  1327. +    a request via TCP use a synchronous TCP session for its forwarding
  1328. +    operation.  The connection management mechanisms of [RFC1035 4.2.2]
  1329. +    are sufficient to prevent large scale damage from such an attack, but
  1330. +    not to prevent some queries from going unanswered during the attack.
  1331. + 
  1332. + Acknowledgements
  1333. + 
  1334. +    We would like to thank the IETF DNSIND working group for their input
  1335. +    and assistance, in particular, Rob Austein, Randy Bush, Donald
  1336. +    Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz.  Special
  1337. +    thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this
  1338. +    document.
  1339. + 
  1340. + 
  1341. + 
  1342. + 
  1343. + 
  1344. + 
  1345. + 
  1346. + 
  1347. + 
  1348. + 
  1349. + 
  1350. + 
  1351. + 
  1352. + 
  1353. + Vixie, et. al.              Standards Track                    [Page 24]
  1354. + 
  1355. + RFC 2136                       DNS Update                     April 1997
  1356. + 
  1357. + 
  1358. + References
  1359. + 
  1360. +    [RFC1035]
  1361. +       Mockapetris, P., "Domain Names - Implementation and
  1362. +       Specification", STD 13, RFC 1035, USC/Information Sciences
  1363. +       Institute, November 1987.
  1364. + 
  1365. +    [RFC1982]
  1366. +       Elz, R., "Serial Number Arithmetic", RFC 1982, University of
  1367. +       Melbourne, August 1996.
  1368. + 
  1369. +    [RFC1995]
  1370. +       Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute
  1371. +       of Technology, August 1996.
  1372. + 
  1373. +    [RFC1996]
  1374. +       Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
  1375. +       RFC 1996, Internet Software Consortium, August 1996.
  1376. + 
  1377. +    [RFC2065]
  1378. +       Eastlake, D., and C. Kaufman, "Domain Name System Protocol
  1379. +       Security Extensions", RFC 2065, January 1997.
  1380. + 
  1381. +    [RFC2137]
  1382. +       Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
  1383. +       2137, April 1997.
  1384. + 
  1385. + Authors' Addresses
  1386. + 
  1387. +    Yakov Rekhter
  1388. +    Cisco Systems
  1389. +    170 West Tasman Drive
  1390. +    San Jose, CA 95134-1706
  1391. + 
  1392. +    Phone: +1 914 528 0090
  1393. +    EMail: yakov@cisco.com
  1394. + 
  1395. + 
  1396. +    Susan Thomson
  1397. +    Bellcore
  1398. +    445 South Street
  1399. +    Morristown, NJ 07960
  1400. + 
  1401. +    Phone: +1 201 829 4514
  1402. +    EMail: set@thumper.bellcore.com
  1403. + 
  1404. + 
  1405. + 
  1406. + 
  1407. + 
  1408. + 
  1409. + Vixie, et. al.              Standards Track                    [Page 25]
  1410. + 
  1411. + RFC 2136                       DNS Update                     April 1997
  1412. + 
  1413. + 
  1414. +    Jim Bound
  1415. +    Digital Equipment Corp.
  1416. +    110 Spitbrook Rd ZK3-3/U14
  1417. +    Nashua, NH 03062-2698
  1418. + 
  1419. +    Phone: +1 603 881 0400
  1420. +    EMail: bound@zk3.dec.com
  1421. + 
  1422. + 
  1423. +    Paul Vixie
  1424. +    Internet Software Consortium
  1425. +    Star Route Box 159A
  1426. +    Woodside, CA 94062
  1427. + 
  1428. +    Phone: +1 415 747 0204
  1429. +    EMail: paul@vix.com
  1430. + 
  1431. + 
  1432. + 
  1433. + 
  1434. + 
  1435. + 
  1436. + 
  1437. + 
  1438. + 
  1439. + 
  1440. + 
  1441. + 
  1442. + 
  1443. + 
  1444. + 
  1445. + 
  1446. + 
  1447. + 
  1448. + 
  1449. + 
  1450. + 
  1451. + 
  1452. + 
  1453. + 
  1454. + 
  1455. + 
  1456. + 
  1457. + 
  1458. + 
  1459. + 
  1460. + 
  1461. + 
  1462. + 
  1463. + 
  1464. + 
  1465. + Vixie, et. al.              Standards Track                    [Page 26]
  1466. + 
  1467. Index: bind/doc/rfc/rfc2137
  1468. diff -c /dev/null bind/doc/rfc/rfc2137:8.1
  1469. *** /dev/null    Wed Apr 30 21:24:39 1997
  1470. --- bind/doc/rfc/rfc2137    Wed Apr 30 10:27:15 1997
  1471. ***************
  1472. *** 0 ****
  1473. --- 1,619 ----
  1474. + 
  1475. + 
  1476. + 
  1477. + 
  1478. + 
  1479. + 
  1480. + Network Working Group                                    D. Eastlake 3rd
  1481. + Request for Comments: 2137                               CyberCash, Inc.
  1482. + Updates: 1035                                                 April 1997
  1483. + Category: Standards Track
  1484. + 
  1485. + 
  1486. +                 Secure Domain Name System Dynamic Update
  1487. + 
  1488. + Status of this Memo
  1489. + 
  1490. +    This document specifies an Internet standards track protocol for the
  1491. +    Internet community, and requests discussion and suggestions for
  1492. +    improvements.  Please refer to the current edition of the "Internet
  1493. +    Official Protocol Standards" (STD 1) for the standardization state
  1494. +    and status of this protocol.  Distribution of this memo is unlimited.
  1495. + 
  1496. + Abstract
  1497. + 
  1498. +    Domain Name System (DNS) protocol extensions have been defined to
  1499. +    authenticate the data in DNS and provide key distribution services
  1500. +    [RFC2065].  DNS Dynamic Update operations have also been defined
  1501. +    [RFC2136], but without a detailed description of security for the
  1502. +    update operation.  This memo describes how to use DNSSEC digital
  1503. +    signatures covering requests and data to secure updates and restrict
  1504. +    updates to those authorized to perform them as indicated by the
  1505. +    updater's possession of cryptographic keys.
  1506. + 
  1507. + Acknowledgements
  1508. + 
  1509. +    The contributions of the following persons (who are listed in
  1510. +    alphabetic order) to this memo are gratefully acknowledged:
  1511. + 
  1512. +          Olafur Gudmundsson (ogud@tis.com>
  1513. +          Charlie Kaufman <Charlie_Kaufman@iris.com>
  1514. +          Stuart Kwan <skwan@microsoft.com>
  1515. +          Edward Lewis <lewis@tis.com>
  1516. + 
  1517. + Table of Contents
  1518. + 
  1519. +       1. Introduction............................................2
  1520. +       1.1 Overview of DNS Dynamic Update.........................2
  1521. +       1.2 Overview of DNS Security...............................2
  1522. +       2. Two Basic Modes.........................................3
  1523. +       3. Keys....................................................5
  1524. +       3.1 Update Keys............................................6
  1525. +       3.1.1 Update Key Name Scope................................6
  1526. +       3.1.2 Update Key Class Scope...............................6
  1527. +       3.1.3 Update Key Signatory Field...........................6
  1528. + 
  1529. + 
  1530. + 
  1531. + Eastlake                    Standards Track                     [Page 1]
  1532. + 
  1533. + RFC 2137                         SDNSDU                       April 1997
  1534. + 
  1535. + 
  1536. +       3.2 Zone Keys and Update Modes.............................8
  1537. +       3.3 Wildcard Key Punch Through.............................9
  1538. +       4. Update Signatures.......................................9
  1539. +       4.1 Update Request Signatures..............................9
  1540. +       4.2 Update Data Signatures................................10
  1541. +       5. Security Considerations................................10
  1542. +       References................................................10
  1543. +       Author's Address..........................................11
  1544. + 
  1545. + 1. Introduction
  1546. + 
  1547. +    Dynamic update operations have been defined for the Domain Name
  1548. +    System (DNS) in RFC 2136, but without a detailed description of
  1549. +    security for those updates.  Means of securing the DNS and using it
  1550. +    for key distribution have been defined in RFC 2065.
  1551. + 
  1552. +    This memo proposes techniques based on the defined DNS security
  1553. +    mechanisms to authenticate DNS updates.
  1554. + 
  1555. +    Familiarity with the DNS system [RFC 1034, 1035] is assumed.
  1556. +    Familiarity with the DNS security and dynamic update proposals will
  1557. +    be helpful.
  1558. + 
  1559. + 1.1 Overview of DNS Dynamic Update
  1560. + 
  1561. +    DNS dynamic update defines a new DNS opcode, new DNS request and
  1562. +    response structure if that opcode is used, and new error codes.  An
  1563. +    update can specify complex combinations of deletion and insertion
  1564. +    (with or without pre-existence testing) of resource records (RRs)
  1565. +    with one or more owner names; however, all testing and changes for
  1566. +    any particular DNS update request are restricted to a single zone.
  1567. +    Updates occur at the primary server for a zone.
  1568. + 
  1569. +    The primary server for a secure dynamic zone must increment the zone
  1570. +    SOA serial number when an update occurs or the next time the SOA is
  1571. +    retrieved if one or more updates have occurred since the previous SOA
  1572. +    retrieval and the updates themselves did not update the SOA.
  1573. + 
  1574. + 1.2 Overview of DNS Security
  1575. + 
  1576. +    DNS security authenticates data in the DNS by also storing digital
  1577. +    signatures in the DNS as SIG resource records (RRs).  A SIG RR
  1578. +    provides a digital signature on the set of all RRs with the same
  1579. +    owner name and class as the SIG and whose type is the type covered by
  1580. +    the SIG.  The SIG RR cryptographically binds the covered RR set to
  1581. +    the signer, time signed, signature expiration date, etc.  There are
  1582. +    one or more keys associated with every secure zone and all data in
  1583. +    the secure zone is signed either by a zone key or by a dynamic update
  1584. + 
  1585. + 
  1586. + 
  1587. + Eastlake                    Standards Track                     [Page 2]
  1588. + 
  1589. + RFC 2137                         SDNSDU                       April 1997
  1590. + 
  1591. + 
  1592. +    key tracing its authority to a zone key.
  1593. + 
  1594. +    DNS security also defines transaction SIGs and request SIGs.
  1595. +    Transaction SIGs appear at the end of a response.  Transaction SIGs
  1596. +    authenticate the response and bind it to the corresponding request
  1597. +    with the key of the host where the responding DNS server is.  Request
  1598. +    SIGs appear at the end of a request and authenticate the request with
  1599. +    the key of the submitting entity.
  1600. + 
  1601. +    Request SIGs are the primary means of authenticating update requests.
  1602. + 
  1603. +    DNS security also permits the storage of public keys in the DNS via
  1604. +    KEY RRs.  These KEY RRs are also, of course, authenticated by SIG
  1605. +    RRs.  KEY RRs for zones are stored in their superzone and subzone
  1606. +    servers, if any, so that the secure DNS tree of zones can be
  1607. +    traversed by a security aware resolver.
  1608. + 
  1609. + 2. Two Basic Modes
  1610. + 
  1611. +    A dynamic secure zone is any secure DNS zone containing one or more
  1612. +    KEY RRs that can authorize dynamic updates, i.e., entity or user KEY
  1613. +    RRs with the signatory field non-zero, and whose zone KEY RR
  1614. +    signatory field indicates that updates are implemented. There are two
  1615. +    basic modes of dynamic secure zone which relate to the update
  1616. +    strategy, mode A and mode B.  A summary comparison table is given
  1617. +    below and then each mode is described.
  1618. + 
  1619. + 
  1620. + 
  1621. + 
  1622. + 
  1623. + 
  1624. + 
  1625. + 
  1626. + 
  1627. + 
  1628. + 
  1629. + 
  1630. + 
  1631. + 
  1632. + 
  1633. + 
  1634. + 
  1635. + 
  1636. + 
  1637. + 
  1638. + 
  1639. + 
  1640. + 
  1641. + 
  1642. + 
  1643. + Eastlake                    Standards Track                     [Page 3]
  1644. + 
  1645. + RFC 2137                         SDNSDU                       April 1997
  1646. + 
  1647. + 
  1648. +                    SUMMARY OF DYNAMIC SECURE ZONE MODES
  1649. + 
  1650. +    CRITERIA:                |   MODE A           |   MODE B
  1651. +    =========================+====================+===================
  1652. +    Definition:              | Zone Key Off line  | Zone Key On line
  1653. +    =========================+====================+===================
  1654. +    Server Workload          |   Low              |   High
  1655. +    -------------------------+--------------------+-------------------
  1656. +    Static Data Security     |   Very High        |   Medium-High
  1657. +    -------------------------+--------------------+-------------------
  1658. +    Dynamic Data Security    |   Medium           |   Medium-High
  1659. +    -------------------------+--------------------+-------------------
  1660. +    Key Restrictions         |   Fine grain       |   Coarse grain
  1661. +    -------------------------+--------------------+-------------------
  1662. +    Dynamic Data Temporality |   Transient        |   Permanent
  1663. +    -------------------------+--------------------+-------------------
  1664. +    Dynamic Key Rollover     |   No               |   Yes
  1665. +    -------------------------+--------------------+-------------------
  1666. + 
  1667. +    For mode A, the zone owner key and static zone master file are always
  1668. +    kept off-line for maximum security of the static zone contents.
  1669. + 
  1670. +    As a consequence, any dynamicly added or changed RRs are signed in
  1671. +    the secure zone by their authorizing dynamic update key and they are
  1672. +    backed up, along with this SIG RR, in a separate online dynamic
  1673. +    master file.  In this type of zone, server computation is minimized
  1674. +    since the server need only check signatures on the update data and
  1675. +    request, which have already been signed by the updater, generally a
  1676. +    much faster operation than signing data.  However, the AXFR SIG and
  1677. +    NXT RRs which covers the zone under the zone key will not cover
  1678. +    dynamically added data.  Thus, for type A dynamic secure zones, zone
  1679. +    transfer security is not automatically provided for dynamically added
  1680. +    RRs, where they could be omitted, and authentication is not provided
  1681. +    for the server denial of the existence of a dynamically added type.
  1682. +    Because the dynamicly added RRs retain their update KEY signed SIG,
  1683. +    finer grained control of updates can be implemented via bits in the
  1684. +    KEY RR signatory field.  Because dynamic data is only stored in the
  1685. +    online dynamic master file and only authenticated by dynamic keys
  1686. +    which expire, updates are transient in nature.  Key rollover for an
  1687. +    entity that can authorize dynamic updates is more cumbersome since
  1688. +    the authority of their key must be traceable to a zone key and so, in
  1689. +    general, they must securely communicate a new key to the zone
  1690. +    authority for manual transfer to the off line static master file.
  1691. +    NOTE: for this mode the zone SOA must be signed by a dynamic update
  1692. +    key and that private key must be kept on line so that the SOA can be
  1693. +    changed for updates.
  1694. + 
  1695. + 
  1696. + 
  1697. + 
  1698. + 
  1699. + Eastlake                    Standards Track                     [Page 4]
  1700. + 
  1701. + RFC 2137                         SDNSDU                       April 1997
  1702. + 
  1703. + 
  1704. +    For mode B, the zone owner key and master file are kept on-line at
  1705. +    the zone primary server. When authenticated updates succeed, SIGs
  1706. +    under the zone key for the resulting data (including the possible NXT
  1707. +    type bit map changes) are calculated and these SIG (and possible NXT)
  1708. +    changes are entered into the zone and the unified on-line master
  1709. +    file.  (The zone transfer AXFR SIG may be recalculated for each
  1710. +    update or on demand when a zone transfer is requested and it is out
  1711. +    of date.)
  1712. + 
  1713. +    As a consequence, this mode requires considerably more computational
  1714. +    effort on the part of the server as the public/private keys are
  1715. +    generally arranged so that signing (calculating a SIG) is more effort
  1716. +    than verifying a signature.  The security of static data in the zone
  1717. +    is decreased because the ultimate state of the static data being
  1718. +    served and the ultimate zone authority private key are all on-line on
  1719. +    the net.  This means that if the primary server is subverted, false
  1720. +    data could be authenticated to secondaries and other
  1721. +    servers/resolvers.  On the other hand, this mode of operation means
  1722. +    that data added dynamically is more secure than in mode A.  Dynamic
  1723. +    data will be covered by the AXFR SIG and thus always protected during
  1724. +    zone transfers and will be included in NXT RRs so that it can be
  1725. +    falsely denied by a server only to the same extent that static data
  1726. +    can (i.e., if it is within a wild card scope). Because the zone key
  1727. +    is used to sign all the zone data, the information as to who
  1728. +    originated the current state of dynamic RR sets is lost, making
  1729. +    unavailable the effects of some of the update control bits in the KEY
  1730. +    RR signatory field.  In addition, the incorporation of the updates
  1731. +    into the primary master file and their authentication by the zone key
  1732. +    makes then permanent in nature.  Maintaining the zone key on-line
  1733. +    also means that dynamic update keys which are signed by the zone key
  1734. +    can be dynamically updated since the zone key is available to
  1735. +    dynamically sign new values.
  1736. + 
  1737. +    NOTE:  The Mode A / Mode B distinction only effects the validation
  1738. +    and performance of update requests.  It has no effect on retrievals.
  1739. +    One reasonable operational scheme may be to keep a mostly static main
  1740. +    zone operating in Mode A and have one or more dynamic subzones
  1741. +    operating in Mode B.
  1742. + 
  1743. + 3. Keys
  1744. + 
  1745. +    Dynamic update requests depend on update keys as described in section
  1746. +    3.1 below.  In addition, the zone secure dynamic update mode and
  1747. +    availability of some options is indicated in the zone key.  Finally,
  1748. +    a special rule is used in searching for KEYs to validate updates as
  1749. +    described in section 3.3.
  1750. + 
  1751. + 
  1752. + 
  1753. + 
  1754. + 
  1755. + Eastlake                    Standards Track                     [Page 5]
  1756. + 
  1757. + RFC 2137                         SDNSDU                       April 1997
  1758. + 
  1759. + 
  1760. + 3.1 Update Keys
  1761. + 
  1762. +    All update requests to a secure zone must include signatures by one
  1763. +    or more key(s) that together can authorize that update.  In order for
  1764. +    the Domain Name System (DNS) server receiving the request to confirm
  1765. +    this, the key or keys must be available to and authenticated by that
  1766. +    server as a specially flagged KEY Resource Record.
  1767. + 
  1768. +    The scope of authority of such keys is indicated by their KEY RR
  1769. +    owner name, class, and signatory field flags as described below. In
  1770. +    addition, such KEY RRs must be entity or user keys and not have the
  1771. +    authentication use prohibited bit on.  All parts of the actual update
  1772. +    must be within the scope of at least one of the keys used for a
  1773. +    request SIG on the update request as described in section 4.
  1774. + 
  1775. + 3.1.1 Update Key Name Scope
  1776. + 
  1777. +    The owner name of any update authorizing KEY RR must (1) be the same
  1778. +    as the owner name of any RRs being added or deleted or (2) a wildcard
  1779. +    name including within its extended scope (see section 3.3) the name
  1780. +    of any RRs being added or deleted and those RRs must be in the same
  1781. +    zone.
  1782. + 
  1783. + 3.1.2 Update Key Class Scope
  1784. + 
  1785. +    The class of any update authorizing KEY RR must be the same as the
  1786. +    class of any RR's being added or deleted.
  1787. + 
  1788. + 3.1.3 Update Key Signatory Field
  1789. + 
  1790. +    The four bit "signatory field" (see RFC 2065) of any update
  1791. +    authorizing KEY RR must be non-zero.  The bits have the meanings
  1792. +    described below for non-zone keys (see section 3.2 for zone type
  1793. +    keys).
  1794. + 
  1795. +                     UPDATE KEY RR SIGNATORY FIELD BITS
  1796. + 
  1797. +          0           1           2           3
  1798. +    +-----------+-----------+-----------+-----------+
  1799. +    |   zone    |  strong   |  unique   |  general  |
  1800. +    +-----------+-----------+-----------+-----------+
  1801. + 
  1802. +    Bit 0, zone control - If nonzero, this key is authorized to attach,
  1803. +         detach, and move zones by creating and deleting NS, glue A, and
  1804. +         zone KEY RR(s).  If zero, the key can not authorize any update
  1805. +         that would effect such RRs.  This bit is meaningful for both
  1806. +         type A and type B dynamic secure zones.
  1807. + 
  1808. + 
  1809. + 
  1810. + 
  1811. + Eastlake                    Standards Track                     [Page 6]
  1812. + 
  1813. + RFC 2137                         SDNSDU                       April 1997
  1814. + 
  1815. + 
  1816. +         NOTE:  do not confuse the "zone" signatory field bit with the
  1817. +         "zone" key type bit.
  1818. + 
  1819. +    Bit 1, strong update - If nonzero, this key is authorized to add and
  1820. +         delete RRs even if there are other RRs with the same owner name
  1821. +         and class that are authenticated by a SIG signed with a
  1822. +         different dynamic update KEY. If zero, the key can only
  1823. +         authorize updates where any existing RRs of the same owner and
  1824. +         class are authenticated by a SIG using the same key.  This bit
  1825. +         is meaningful only for type A dynamic zones and is ignored in
  1826. +         type B dynamic zones.
  1827. + 
  1828. +         Keeping this bit zero on multiple KEY RRs with the same or
  1829. +         nested wild card owner names permits multiple entities to exist
  1830. +         that can create and delete names but can not effect RRs with
  1831. +         different owner names from any they created.  In effect, this
  1832. +         creates two levels of dynamic update key, strong and weak, where
  1833. +         weak keys are limited in interfering with each other but a
  1834. +         strong key can interfere with any weak keys or other strong
  1835. +         keys.
  1836. + 
  1837. +    Bit 2, unique name update - If nonzero, this key is authorized to add
  1838. +         and update RRs for only a single owner name.  If there already
  1839. +         exist RRs with one or more names signed by this key, they may be
  1840. +         updated but no new name created until the number of existing
  1841. +         names is reduced to zero.  This bit is meaningful only for mode
  1842. +         A dynamic zones and is ignored in mode B dynamic zones. This bit
  1843. +         is meaningful only if the owner name is a wildcard.  (Any
  1844. +         dynamic update KEY with a non-wildcard name is, in effect, a
  1845. +         unique name update key.)
  1846. + 
  1847. +         This bit can be used to restrict a KEY from flooding a zone with
  1848. +         new names.  In conjunction with a local administratively imposed
  1849. +         limit on the number of dynamic RRs with a particular name, it
  1850. +         can completely restrict a KEY from flooding a zone with RRs.
  1851. + 
  1852. +    Bit 3, general update - The general update signatory field bit has no
  1853. +         special meaning.  If the other three bits are all zero, it must
  1854. +         be one so that the field is non-zero to designate that the key
  1855. +         is an update key.  The meaning of all values of the signatory
  1856. +         field with the general bit and one or more other signatory field
  1857. +         bits on is reserved.
  1858. + 
  1859. +    All the signatory bit update authorizations described above only
  1860. +    apply if the update is within the name and class scope as per
  1861. +    sections 3.1.1 and 3.1.2.
  1862. + 
  1863. + 
  1864. + 
  1865. + 
  1866. + 
  1867. + Eastlake                    Standards Track                     [Page 7]
  1868. + 
  1869. + RFC 2137                         SDNSDU                       April 1997
  1870. + 
  1871. + 
  1872. + 3.2 Zone Keys and Update Modes
  1873. + 
  1874. +    Zone type keys are automatically authorized to sign anything in their
  1875. +    zone, of course, regardless of the value of their signatory field.
  1876. +    For zone keys, the signatory field bits have different means than
  1877. +    they they do for update keys, as shown below.  The signatory field
  1878. +    MUST be zero if dynamic update is not supported for a zone and MUST
  1879. +    be non-zero if it is.
  1880. + 
  1881. +                      ZONE KEY RR SIGNATORY FIELD BITS
  1882. + 
  1883. +                   0           1           2           3
  1884. +             +-----------+-----------+-----------+-----------+
  1885. +             |   mode    |  strong   |  unique   |  general  |
  1886. +             +-----------+-----------+-----------+-----------+
  1887. + 
  1888. +    Bit 0, mode - This bit indicates the update mode for this zone.  Zero
  1889. +         indicates mode A while a one indicates mode B.
  1890. + 
  1891. +    Bit 1, strong update - If nonzero, this indicates that the "strong"
  1892. +         key feature described in section 3.1.3 above is implemented and
  1893. +         enabled for this secure zone.  If zero, the feature is not
  1894. +         available.  Has no effect if the zone is a mode B secure update
  1895. +         zone.
  1896. + 
  1897. +    Bit 2, unique name update - If nonzero, this indicates that the
  1898. +         "unique name" feature described in section 3.1.3 above is
  1899. +         implemented and enabled for this secure zone.  If zero, this
  1900. +         feature is not available.  Has no effect if the zone is a mode B
  1901. +         secure update zone.
  1902. + 
  1903. +    Bit 3, general - This bit has no special meeting.  If dynamic update
  1904. +         for a zone is supported and the other bits in the zone key
  1905. +         signatory field are zero, it must be a one.  The meaning of zone
  1906. +         keys where the signatory field has the general bit and one or
  1907. +         more other bits on is reserved.
  1908. + 
  1909. +    If there are multiple dynamic update KEY RRs for a zone and zone
  1910. +    policy is in transition, they might have different non-zero signatory
  1911. +    fields.  In that case, strong and unique name restrictions must be
  1912. +    enforced as long as there is a non-expired zone key being advertised
  1913. +    that indicates mode A with the strong or unique name bit on
  1914. +    respectively.  Mode B updates MUST be supported as long as there is a
  1915. +    non-expired zone key that indicates mode B.  Mode A updates may be
  1916. +    treated as mode B updates at server option if non-expired zone keys
  1917. +    indicate that both are supported.
  1918. + 
  1919. + 
  1920. + 
  1921. + 
  1922. + 
  1923. + Eastlake                    Standards Track                     [Page 8]
  1924. + 
  1925. + RFC 2137                         SDNSDU                       April 1997
  1926. + 
  1927. + 
  1928. +    A server that will be executing update operations on a zone, that is,
  1929. +    the primary master server, MUST not advertize a zone key that will
  1930. +    attract requests for a mode or features that it can not support.
  1931. + 
  1932. + 3.3 Wildcard Key Punch Through
  1933. + 
  1934. +    Just as a zone key is valid throughout the entire zone, update keys
  1935. +    with wildcard names are valid throughout their extended scope, within
  1936. +    the zone. That is, they remain valid for any name that would match
  1937. +    them, even existing specific names within their apparent scope.
  1938. + 
  1939. +    If this were not so, then whenever a name within a wildcard scope was
  1940. +    created by dynamic update, it would be necessary to first create a
  1941. +    copy of the KEY RR with this name, because otherwise the existence of
  1942. +    the more specific name would hide the authorizing KEY RR and would
  1943. +    make later updates impossible.  An updater could create such a KEY RR
  1944. +    but could not zone sign it with their authorizing signer.  They would
  1945. +    have to sign it with the same key using the wildcard name as signer.
  1946. +    Thus in creating, for example, one hundred type A RRs authorized by a
  1947. +    *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100
  1948. +    KEYs, and 200 SIGs would have to be created as opposed to merely 100
  1949. +    As and 100 SIGs with key punch through.
  1950. + 
  1951. + 4. Update Signatures
  1952. + 
  1953. +    Two kinds of signatures can appear in updates.  Request signatures,
  1954. +    which are always required, cover the entire request and authenticate
  1955. +    the DNS header, including opcode, counts, etc., as well as the data.
  1956. +    Data signatures, on the other hand, appear only among the RRs to be
  1957. +    added and are only required for mode A operation.  These two types of
  1958. +    signatures are described further below.
  1959. + 
  1960. + 4.1 Update Request Signatures
  1961. + 
  1962. +    An update can effect multiple owner names in a zone.  It may be that
  1963. +    these different names are covered by different dynamic update keys.
  1964. +    For every owner name effected, the updater must know a private key
  1965. +    valid for that name (and the zone's class) and must prove this by
  1966. +    appending request SIG RRs under each such key.
  1967. + 
  1968. +    As specified in RFC 2065, a request signature is a SIG RR occurring
  1969. +    at the end of a request with a type covered field of zero.  For an
  1970. +    update, request signatures occur in the Additional information
  1971. +    section.  Each request SIG signs the entire request, including DNS
  1972. +    header, but excluding any other request SIG(s) and with the ARCOUNT
  1973. +    in the DNS header set to what it wold be without the request SIGs.
  1974. + 
  1975. + 
  1976. + 
  1977. + 
  1978. + 
  1979. + Eastlake                    Standards Track                     [Page 9]
  1980. + 
  1981. + RFC 2137                         SDNSDU                       April 1997
  1982. + 
  1983. + 
  1984. + 4.2 Update Data Signatures
  1985. + 
  1986. +    Mode A dynamic secure zones require that the update requester provide
  1987. +    SIG RRs that will authenticate the after update state of all RR sets
  1988. +    that are changed by the update and are non-empty after the update.
  1989. +    These SIG RRs appear in the request as RRs to be added and the
  1990. +    request must delete any previous data SIG RRs that are invalidated by
  1991. +    the request.
  1992. + 
  1993. +    In Mode B dynamic secure zones, all zone data is authenticated by
  1994. +    zone key SIG RRs.  In this case, data signatures need not be included
  1995. +    with the update.  A resolver can determine which mode an updatable
  1996. +    secure zone is using by examining the signatory field bits of the
  1997. +    zone KEY RR (see section 3.2).
  1998. + 
  1999. + 5. Security Considerations
  2000. + 
  2001. +    Any zone permitting dynamic updates is inherently less secure than a
  2002. +    static secure zone maintained off line as recommended in RFC 2065. If
  2003. +    nothing else, secure dynamic update requires on line change to and
  2004. +    re-signing of the zone SOA resource record (RR) to increase the SOA
  2005. +    serial number.  This means that compromise of the primary server host
  2006. +    could lead to arbitrary serial number changes.
  2007. + 
  2008. +    Isolation of dynamic RRs to separate zones from those holding most
  2009. +    static RRs can limit the damage that could occur from breach of a
  2010. +    dynamic zone's security.
  2011. + 
  2012. + References
  2013. + 
  2014. +    [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security
  2015. +    Extensions", RFC 2065, CyberCash, Iris, January 1997.
  2016. + 
  2017. +    [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound,
  2018. +    "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
  2019. +    April 1997.
  2020. + 
  2021. +    [RFC1035] Mockapetris, P., "Domain Names - Implementation and
  2022. +    Specifications", STD 13, RFC 1035, November 1987.
  2023. + 
  2024. +    [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
  2025. +    STD 13, RFC 1034, November 1987.
  2026. + 
  2027. + 
  2028. + 
  2029. + 
  2030. + 
  2031. + 
  2032. + 
  2033. + 
  2034. + 
  2035. + Eastlake                    Standards Track                    [Page 10]
  2036. + 
  2037. + RFC 2137                         SDNSDU                       April 1997
  2038. + 
  2039. + 
  2040. + Author's Address
  2041. + 
  2042. +    Donald E. Eastlake, 3rd
  2043. +    CyberCash, Inc.
  2044. +    318 Acton Street
  2045. +    Carlisle, MA 01741 USA
  2046. + 
  2047. +    Phone:   +1 508-287-4877
  2048. +             +1 508-371-7148 (fax)
  2049. +             +1 703-620-4200 (main office, Reston, Virginia, USA)
  2050. +    EMail:   dee@cybercash.com
  2051. + 
  2052. + 
  2053. + 
  2054. + 
  2055. + 
  2056. + 
  2057. + 
  2058. + 
  2059. + 
  2060. + 
  2061. + 
  2062. + 
  2063. + 
  2064. + 
  2065. + 
  2066. + 
  2067. + 
  2068. + 
  2069. + 
  2070. + 
  2071. + 
  2072. + 
  2073. + 
  2074. + 
  2075. + 
  2076. + 
  2077. + 
  2078. + 
  2079. + 
  2080. + 
  2081. + 
  2082. + 
  2083. + 
  2084. + 
  2085. + 
  2086. + 
  2087. + 
  2088. + 
  2089. + 
  2090. + 
  2091. + Eastlake                    Standards Track                    [Page 11]
  2092. + 
  2093. Index: bind/src/CHANGES
  2094. diff -c bind/src/CHANGES:8.9 bind/src/CHANGES:8.10
  2095. *** bind/src/CHANGES:8.9    Mon Apr 28 12:16:19 1997
  2096. --- bind/src/CHANGES    Wed Apr 30 15:38:10 1997
  2097. ***************
  2098. *** 1,4 ****
  2099. --- 1,18 ----
  2100.   
  2101. +     --- 8.1-T5B released ---
  2102. + 
  2103. +  182.    [bug]        fix the way bindname is allocated in hesiod_to_bind().
  2104. + 
  2105. +  181.    [bug]        MAXHOSTNAMELEN wasn't defined on Solaris.
  2106. + 
  2107. +  180.    [bug]        a check for zptr != NULL in res_update was wrong.  It
  2108. +             should have been zptr == NULL.
  2109. + 
  2110. +  179.    [bug]        sq_remove() and sq_done() were calling ns_freexfr()
  2111. +             when any stream was removed, resulting in a panic
  2112. +             when the server was reloaded.  ns_freexfr() is now
  2113. +             only called when a zone transfer stream is removed.
  2114. + 
  2115.       --- 8.1-T4B released ---
  2116.   
  2117.    178.    [bug]        if the server was reloaded and then a zone was
  2118. Index: bind/src/README
  2119. diff -c bind/src/README:8.14 bind/src/README:8.15
  2120. *** bind/src/README:8.14    Fri Apr 25 22:59:02 1997
  2121. --- bind/src/README    Wed Apr 30 15:38:10 1997
  2122. ***************
  2123. *** 1,4 ****
  2124. ! This is the source portion of BIND version 8.1-T4B.  Its companions are
  2125.   "doc" and "contrib" so you are probably not missing anything.
  2126.   
  2127.   BIND 8 Features
  2128. --- 1,4 ----
  2129. ! This is the source portion of BIND version 8.1-T5B.  Its companions are
  2130.   "doc" and "contrib" so you are probably not missing anything.
  2131.   
  2132.   BIND 8 Features
  2133. Index: bind/src/Version
  2134. diff -c bind/src/Version:8.5 bind/src/Version:8.6
  2135. *** bind/src/Version:8.5    Thu Apr 24 18:31:39 1997
  2136. --- bind/src/Version    Wed Apr 30 15:38:11 1997
  2137. ***************
  2138. *** 1 ****
  2139. ! 8.1-T4B
  2140. --- 1 ----
  2141. ! 8.1-T5B
  2142. Index: bind/src/bin/named/ns_defs.h
  2143. diff -c bind/src/bin/named/ns_defs.h:8.30 bind/src/bin/named/ns_defs.h:8.31
  2144. *** bind/src/bin/named/ns_defs.h:8.30    Thu Apr 24 16:02:27 1997
  2145. --- bind/src/bin/named/ns_defs.h    Wed Apr 30 15:40:21 1997
  2146. ***************
  2147. *** 1,6 ****
  2148.   /*
  2149.    *    from ns.h    4.33 (Berkeley) 8/23/90
  2150. !  *    $Id: ns_defs.h,v 8.30 1997/04/24 23:02:27 vixie Exp $
  2151.    */
  2152.   
  2153.   /*
  2154. --- 1,6 ----
  2155.   /*
  2156.    *    from ns.h    4.33 (Berkeley) 8/23/90
  2157. !  *    $Id: ns_defs.h,v 8.31 1997/04/30 22:40:21 halley Exp $
  2158.    */
  2159.   
  2160.   /*
  2161. ***************
  2162. *** 456,461 ****
  2163. --- 456,462 ----
  2164.   #define STREAM_READ_EV        0x04
  2165.   #define STREAM_CONNECT_EV    0x08
  2166.   #define STREAM_DONE_CLOSE    0x10
  2167. + #define STREAM_AXFR        0x20
  2168.   
  2169.   struct netinfo {
  2170.       struct netinfo    *next;
  2171. Index: bind/src/bin/named/ns_main.c
  2172. diff -c bind/src/bin/named/ns_main.c:8.49 bind/src/bin/named/ns_main.c:8.50
  2173. *** bind/src/bin/named/ns_main.c:8.49    Thu Apr 24 18:31:45 1997
  2174. --- bind/src/bin/named/ns_main.c    Wed Apr 30 15:40:22 1997
  2175. ***************
  2176. *** 1,6 ****
  2177.   #if !defined(lint) && !defined(SABER)
  2178.   static char sccsid[] = "@(#)ns_main.c    4.55 (Berkeley) 7/1/91";
  2179. ! static char rcsid[] = "$Id: ns_main.c,v 8.49 1997/04/25 01:31:45 vixie Exp $";
  2180.   #endif /* not lint */
  2181.   
  2182.   /*
  2183. --- 1,6 ----
  2184.   #if !defined(lint) && !defined(SABER)
  2185.   static char sccsid[] = "@(#)ns_main.c    4.55 (Berkeley) 7/1/91";
  2186. ! static char rcsid[] = "$Id: ns_main.c,v 8.50 1997/04/30 22:40:22 halley Exp $";
  2187.   #endif /* not lint */
  2188.   
  2189.   /*
  2190. ***************
  2191. *** 1291,1297 ****
  2192.           INSIST_ERR(evDeselectFD(ev, qp->evID_w) != -1);
  2193.       if (qp->flags & STREAM_CONNECT_EV)
  2194.           INSIST_ERR(evCancelConn(ev, qp->evID_c) != -1);
  2195. !     ns_freexfr(qp);
  2196.       (void) close(qp->s_rfd);
  2197.       if (qp == streamq)
  2198.           streamq = qp->s_next;
  2199. --- 1291,1298 ----
  2200.           INSIST_ERR(evDeselectFD(ev, qp->evID_w) != -1);
  2201.       if (qp->flags & STREAM_CONNECT_EV)
  2202.           INSIST_ERR(evCancelConn(ev, qp->evID_c) != -1);
  2203. !     if (qp->flags & STREAM_AXFR)
  2204. !         ns_freexfr(qp);
  2205.       (void) close(qp->s_rfd);
  2206.       if (qp == streamq)
  2207.           streamq = qp->s_next;
  2208. ***************
  2209. *** 1510,1516 ****
  2210.           free(sp->s_wbuf);
  2211.           sp->s_wbuf = NULL;
  2212.       }
  2213. !     ns_freexfr(sp);
  2214.       sp->s_refcnt = 0;
  2215.       sp->s_time = tt.tv_sec;
  2216.       if (sp->flags & STREAM_DONE_CLOSE) {
  2217. --- 1511,1518 ----
  2218.           free(sp->s_wbuf);
  2219.           sp->s_wbuf = NULL;
  2220.       }
  2221. !     if (sp->flags & STREAM_AXFR)
  2222. !         ns_freexfr(sp);
  2223.       sp->s_refcnt = 0;
  2224.       sp->s_time = tt.tv_sec;
  2225.       if (sp->flags & STREAM_DONE_CLOSE) {
  2226. Index: bind/src/bin/named/ns_xfr.c
  2227. diff -c bind/src/bin/named/ns_xfr.c:8.16 bind/src/bin/named/ns_xfr.c:8.17
  2228. *** bind/src/bin/named/ns_xfr.c:8.16    Thu Apr 24 16:58:51 1997
  2229. --- bind/src/bin/named/ns_xfr.c    Wed Apr 30 15:40:22 1997
  2230. ***************
  2231. *** 1,5 ****
  2232.   #if !defined(lint) && !defined(SABER)
  2233. ! static char rcsid[] = "$Id: ns_xfr.c,v 8.16 1997/04/24 23:58:51 vixie Exp $";
  2234.   #endif /* not lint */
  2235.   
  2236.   /*
  2237. --- 1,5 ----
  2238.   #if !defined(lint) && !defined(SABER)
  2239. ! static char rcsid[] = "$Id: ns_xfr.c,v 8.17 1997/04/30 22:40:22 halley Exp $";
  2240.   #endif /* not lint */
  2241.   
  2242.   /*
  2243. ***************
  2244. *** 103,108 ****
  2245. --- 103,109 ----
  2246.                 (char *)&sndlowat, sizeof sndlowat);
  2247.   #endif
  2248.       zones[zone].z_numxfrs++;
  2249. +     qsp->flags |= STREAM_AXFR;
  2250.       if (sq_openw(qsp, 64*1024) == -1)
  2251.           goto abort;
  2252.       memset(&qsp->xfr, 0, sizeof qsp->xfr);
  2253. ***************
  2254. *** 165,170 ****
  2255. --- 166,172 ----
  2256.       while (qsp->xfr.lev)
  2257.           qsp->xfr.lev = sx_freelev(qsp->xfr.lev);
  2258.       zones[qsp->xfr.zone].z_numxfrs--;
  2259. +     qsp->flags &= ~STREAM_AXFR;
  2260.   }
  2261.   
  2262.   /* u_char *
  2263. Index: bind/src/lib/irs/hesiod.c
  2264. diff -c bind/src/lib/irs/hesiod.c:1.13 bind/src/lib/irs/hesiod.c:1.14
  2265. *** bind/src/lib/irs/hesiod.c:1.13    Thu Apr 24 15:34:14 1997
  2266. --- bind/src/lib/irs/hesiod.c    Wed Apr 30 15:39:02 1997
  2267. ***************
  2268. *** 1,5 ****
  2269.   #if defined(LIBC_SCCS) && !defined(lint)
  2270. ! static const char rcsid[] = "$Id: hesiod.c,v 1.13 1997/04/24 22:34:14 vixie Exp $";
  2271.   #endif
  2272.   
  2273.   /*
  2274. --- 1,5 ----
  2275.   #if defined(LIBC_SCCS) && !defined(lint)
  2276. ! static const char rcsid[] = "$Id: hesiod.c,v 1.14 1997/04/30 22:39:02 halley Exp $";
  2277.   #endif
  2278.   
  2279.   /*
  2280. ***************
  2281. *** 164,187 ****
  2282.   char *
  2283.   hesiod_to_bind(void *context, const char *name, const char *type) {
  2284.       struct hesiod_p *ctx = (struct hesiod_p *) context;
  2285. !     char bindname[MAXDNAME], *cp, *ret;
  2286.       char **rhs_list = NULL;
  2287. !     const char *RHS;
  2288. !     
  2289. !     strcpy(bindname, name);
  2290. !     if ((cp = strchr(bindname, '@')) != NULL) {
  2291. !         *cp++ = '\0';
  2292. !         if (strchr(cp, '.'))
  2293. !             RHS = name + (cp - bindname);
  2294. !         else if (NULL != (rhs_list = hesiod_resolve(context, cp,
  2295. !                                 "rhs-extension")))
  2296.               RHS = *rhs_list;
  2297.           else {
  2298.               errno = ENOENT;
  2299.               return (NULL);
  2300.           }
  2301. !     } else
  2302.           RHS = ctx->RHS;
  2303.       strcat(bindname, ".");
  2304.       strcat(bindname, type);
  2305.       if (ctx->LHS) {
  2306. --- 164,204 ----
  2307.   char *
  2308.   hesiod_to_bind(void *context, const char *name, const char *type) {
  2309.       struct hesiod_p *ctx = (struct hesiod_p *) context;
  2310. !     char *bindname;
  2311.       char **rhs_list = NULL;
  2312. !     const char *RHS, *cp;
  2313. ! 
  2314. !     /* Decide what our RHS is, and set cp to the end of the actual name. */
  2315. !     if ((cp = strchr(name, '@')) != NULL) {
  2316. !         if (strchr(cp + 1, '.'))
  2317. !             RHS = cp + 1;
  2318. !         else if ((rhs_list = hesiod_resolve(context, cp + 1,
  2319. !             "rhs-extension")) != NULL)
  2320.               RHS = *rhs_list;
  2321.           else {
  2322.               errno = ENOENT;
  2323.               return (NULL);
  2324.           }
  2325. !     } else {
  2326.           RHS = ctx->RHS;
  2327. +         cp = name + strlen(name);
  2328. +     }
  2329. + 
  2330. +     /*
  2331. +      * Allocate the space we need, including up to three periods and
  2332. +      * the terminating NUL.
  2333. +      */
  2334. +     if ((bindname = malloc((cp - name) + strlen(type) + strlen(RHS) +
  2335. +         (ctx->LHS ? strlen(ctx->LHS) : 0) + 4)) == NULL) {
  2336. +         errno = ENOMEM;
  2337. +         if (rhs_list)
  2338. +             hesiod_free_list(context, rhs_list);
  2339. +         return NULL;
  2340. +     }
  2341. + 
  2342. +     /* Now put together the DNS name. */
  2343. +     memcpy(bindname, name, cp - name);
  2344. +     bindname[cp - name] = '\0';
  2345.       strcat(bindname, ".");
  2346.       strcat(bindname, type);
  2347.       if (ctx->LHS) {
  2348. ***************
  2349. *** 190,206 ****
  2350.           strcat(bindname, ctx->LHS);
  2351.       }
  2352.       if (RHS[0] != '.')
  2353. !         strcat(bindname,".");
  2354.       strcat(bindname, RHS);
  2355.       if (rhs_list)
  2356.           hesiod_free_list(context, rhs_list);
  2357. !     ret = malloc(strlen(bindname) + 1);
  2358. !     if (!ret) {
  2359. !         errno = ENOMEM;
  2360. !         return (NULL);
  2361. !     }
  2362. !     strcpy(ret, bindname);
  2363. !     return (ret);
  2364.   }
  2365.   
  2366.   /*
  2367. --- 207,219 ----
  2368.           strcat(bindname, ctx->LHS);
  2369.       }
  2370.       if (RHS[0] != '.')
  2371. !         strcat(bindname, ".");
  2372.       strcat(bindname, RHS);
  2373. + 
  2374.       if (rhs_list)
  2375.           hesiod_free_list(context, rhs_list);
  2376. ! 
  2377. !     return (bindname);
  2378.   }
  2379.   
  2380.   /*
  2381. Index: bind/src/lib/resolv/res_update.c
  2382. diff -c bind/src/lib/resolv/res_update.c:1.10 bind/src/lib/resolv/res_update.c:1.11
  2383. *** bind/src/lib/resolv/res_update.c:1.10    Fri Apr 25 21:01:35 1997
  2384. --- bind/src/lib/resolv/res_update.c    Wed Apr 30 15:39:33 1997
  2385. ***************
  2386. *** 1,5 ****
  2387.   #if !defined(lint) && !defined(SABER)
  2388. ! static char rcsid[] = "$Id: res_update.c,v 1.10 1997/04/26 04:01:35 vixie Exp $";
  2389.   #endif /* not lint */
  2390.   
  2391.   /*
  2392. --- 1,5 ----
  2393.   #if !defined(lint) && !defined(SABER)
  2394. ! static char rcsid[] = "$Id: res_update.c,v 1.11 1997/04/30 22:39:33 halley Exp $";
  2395.   #endif /* not lint */
  2396.   
  2397.   /*
  2398. ***************
  2399. *** 320,326 ****
  2400.                   if (strcasecmp(zname, zptr->z_origin) == 0)
  2401.                   break;
  2402.               }
  2403. !             if (zptr != NULL)
  2404.                   /* should not happen */
  2405.                   return (-1);
  2406.               if (nscount > 0) {
  2407. --- 320,326 ----
  2408.                   if (strcasecmp(zname, zptr->z_origin) == 0)
  2409.                   break;
  2410.               }
  2411. !             if (zptr == NULL)
  2412.                   /* should not happen */
  2413.                   return (-1);
  2414.               if (nscount > 0) {
  2415. Index: bind/src/port/solaris/include/port_after.h
  2416. diff -c bind/src/port/solaris/include/port_after.h:1.5 bind/src/port/solaris/include/port_after.h:1.6
  2417. *** bind/src/port/solaris/include/port_after.h:1.5    Mon Feb 10 15:04:20 1997
  2418. --- bind/src/port/solaris/include/port_after.h    Wed Apr 30 15:41:40 1997
  2419. ***************
  2420. *** 50,52 ****
  2421. --- 50,60 ----
  2422.   
  2423.   #define NEED_DAEMON
  2424.   int daemon(int nochdir, int noclose);
  2425. + 
  2426. + /*
  2427. +  * Solaris defines this in <netdb.h> instead of in <sys/param.h>.  We don't
  2428. +  * define it in our <netdb.h>, so we define it here.
  2429. +  */
  2430. + #ifndef MAXHOSTNAMELEN
  2431. + #define MAXHOSTNAMELEN 256
  2432. + #endif
  2433.